PostgreSQL vence na adoção real, não só na pesquisa de popularidade

- Leitura
- 17 min
- Tabelas
- 1
- Fontes
- 1
Levantamento vai além do ranking DB-Engines e mostra PostgreSQL à frente em pesquisa de desenvolvedores, aquisições bilionárias e escolha automática de agentes de IA.
O que diz quem usa, não quem procura
O autor do blog Planet PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → publicou em 7 de novembro de 2026 uma sequência ao texto de 3 de novembro em que apoiava seu argumento quase inteiramente no ranking DB-Engines. Depois de ser cobrado nos comentários, ele foi atrás de evidência que não depende de um único site de popularidade: pesquisas de uso, dinheiro de aquisição e o comportamento de quem constrói software hoje.
O número mais sólido vem da pesquisa Stack Overflow Developer Survey de 2025: 55,6% de todos os respondentes disseram usar PostgreSQL, contra 48,7% em 2024. Entre desenvolvedores profissionais, o índice sobe para 58,2%, cerca de 18 pontos à frente do MySQL. PostgreSQL também liderou as listas de banco mais admirado e mais desejado mais uma vez.
A diferença para o DB-Engines importa: ranking de busca mede interesse e marketing; pesquisa de desenvolvedor mede quem efetivamente coloca a mão na ferramenta todos os dias. É um sinal mais próximo de adoção real, embora ainda não seja contagem de instalação nem de receita, como o próprio autor reconhece.
O dinheiro que comprou PostgreSQL
Na publicação anterior, o autor mencionara, sem nomear, que fornecedores de big data e IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → vinham comprando empresas PostgreSQL. Desta vez ele deu os nomes e os valores.
| Data | Comprador | Empresa adquirida | Valor reportado |
|---|---|---|---|
| Outubro de 2025 | Accel e Peak XV (investidores) | Supabase, Série E | US$ 5 bilhões de avaliação |
| Junho de 2025 | Snowflake | Crunchy Data | cerca de US$ 250 milhões, não confirmado |
| Maio de 2025 | Databricks | Neon | cerca de US$ 1 bilhão |
O detalhe que chama atenção é a velocidade: a Supabase valia US$ 2 bilhões em abril de 2025 e passou para US$ 5 bilhões seis meses depois. Snowflake e Databricks, as duas empresas mais citadas como ameaça aos bancos relacionais tradicionais, decidiram que precisavam ter PostgreSQL dentro de casa.
Quando o concorrente vende o que diz que bate
Mais revelador que a tabela de aquisições é olhar o catálogo dos próprios rivais de PostgreSQL no topo dos rankings relacionais. Os quatro líderes históricos, ou os donos deles, vendem PostgreSQL como produto:
- A Oracle opera o OCI Database with PostgreSQL, e o próprio blog de MySQL da empresa publicou um texto recomendando migrar PostgreSQL para o OCI.
- A Microsoft anunciou o Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → HorizonDB, um motor PostgreSQL nativo de nuvem, no Ignite 2025, ao lado do já existente Azure Database for PostgreSQL. A empresa também está entre os maiores contribuidores corporativos do projeto.
- A Amazon, que não tem banco próprio no top-quatro mas roda a maior nuvem do mercado, vende RDS, Aurora e o Aurora DSQL, todos compatíveis com PostgreSQL.
Quando as empresas que supostamente estão perdendo posição constroem produto em cima de quem supostamente as está batendo, isso diz mais sobre quem está ganhando do que qualquer pesquisa de popularidade.
O protocolo pode estar vencendo mais que o banco
Para quem desenvolve, o detalhe mais prático do levantamento é outro: bancos que não são PostgreSQL cada vez mais fingem ser PostgreSQL. CockroachDB, YugabyteDB, Google AlloyDB, a interface PostgreSQL do Google Spanner, Aurora DSQL, Materialize e RisingWave falam o protocolo de fio do PostgreSQL e algum dialeto do seu SQL.
Isso significa que psql, drivers JDBC e qualquer ORM ou ferramenta gráfica escrita para PostgreSQL, inclusive o DBeaver, já funcionam com eles sem adaptação. Um fornecedor de banco de dados novo em 2026 escolhe compatibilidade com PostgreSQL pela mesma razão que um notebook escolhe USB-C: é onde os usuários e as ferramentas já estão.
Em resumo: assim como SQL virou a interface comum do relacional nos anos 1990, o dialeto e o protocolo do PostgreSQL estão virando a interface comum desta geração de bancos distribuídos e serverless. É uma forma de vitória que nenhum ranking de popularidade capta, porque o nome que aparece na tela de login pode nem ser PostgreSQL.
Os agentes de IA já escolheram
A parte mais nova do argumento é sobre quem decide a arquitetura quando ninguém está decidindo por hábito ou contrato corporativo: os agentes de IA. Quando a Databricks anunciou a compra da Neon, em maio de 2025, revelou que mais de 80% dos bancos de dados criados na plataforma eram gerados por agentes de IA, não por pessoas.
Ferramentas de geração de aplicação por prompt, o chamado vibe coding, recorrem majoritariamente à Supabase, que é PostgreSQL por baixo. O próprio autor sugere um teste simples: pedir a um assistente de código para montar um app com banco de dados e observar o que ele escolhe.
Isso cria um funil silencioso: cada protótipo gerado por IA que vira produto real carrega PostgreSQL junto, sem que ninguém tenha batido o martelo numa reunião de arquitetura. É adoção por inércia de ferramenta, não por convicção técnica, mas adoção mesmo assim.
Escala não é mais desculpa
Um argumento clássico contra PostgreSQL em ambientes corporativos é que ele resolve bem até certo tamanho e depois esbarra em limite de escala. Em janeiro de 2026, a OpenAI descreveu publicamente como roda o banco de dados central do ChatGPT: um único servidor primário no Azure Database for PostgreSQL, com quase 50 réplicas de leitura espalhadas por regiões, atendendo 800 milhões de usuários e milhões de consultas por segundo.
Não é receita simples de copiar: exige disciplina de engenharia em torno de réplicas, roteamento de leitura e particionamento de carga que poucas equipes vão precisar replicar. Mas como argumento de que PostgreSQL não aguenta porte grande, o caso da OpenAI deixa a objeção sem muito chão.
O que ainda não é vitória
O próprio levantamento reconhece onde PostgreSQL não está ganhando, e vale registrar para não cair em entusiasmo fácil:
- MySQL segue em praticamente toda pilha LAMP e site WordPress↳WordPress9 conteúdosAndroid push notifications com Quasar Framework, Firebase e integração com WordPressDev (Back & Front) · mai 2019Simplificando a acessibilidade de documentos: introduzindo a integração do ONLYOFFICE DocSpace com WordPress e DrupalDev (Back & Front) · abr 2024Como criar seu site WordPress com um único prompt de IA em minutos?Dev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → existente; base instalada não migra por causa de pesquisa de opinião.
- SQLite é, de longe, o banco mais implantado do planeta, embutido em telefone, navegador e sistema automotivo.
- O trabalho analítico pesado está migrando para plataformas lakehouse como Databricks e Snowflake, não para PostgreSQL: a vitória descrita é operacional, não analítica.
- Oracle e SQL Server seguem donos dos sistemas corporativos mais exigentes, com RAC, Exadata e décadas de ferramental que PostgreSQL ainda não replica integralmente.
Há também um argumento de estabilidade de licença que pesa além do técnico: MongoDB mudou para SSPL, Elastic e Redis trocaram de licença, HashiCorp migrou para BSL. PostgreSQL não tem dono único que possa fazer esse movimento, porque a licença é permissiva e ninguém detém o projeto. Para quem planeja arquitetura num horizonte de cinco ou dez anos, essa previsibilidade de licenciamento pesa tanto quanto qualquer número de desempenho.
O que muda para quem constrói
Para o time que escolhe banco de dados hoje, a conclusão prática do levantamento não é usar sempre PostgreSQL, mas algo mais específico: compatibilidade de protocolo reduz dependência de um único fornecedor de driver ou ORM, extensões como pgvector chegam mais rápido do que qualquer ciclo de release do núcleo, e escolher um banco compatível com PostgreSQL hoje não fecha a porta para trocar de fornecedor depois, porque o cliente de conexão continua o mesmo.
PostgreSQL 19 tem lançamento previsto para 19 de novembro de 2026, e o autor promete revisar o argumento depois, com os números de dezembro do DB-Engines. Até lá, a evidência que ele reuniu não está concentrada numa única métrica: está espalhada entre pesquisa de desenvolvedor, contrato de aquisição, catálogo de nuvem e comportamento de agente de IA na hora de decidir onde gravar dados.
Fonte 1: Planet PostgreSQL (https://postgr.es/p/9Be)
Is PostgreSQL Really Winning Part 2: The Evidence Beyond the Rankings
Skip to main content
Get link
X
Other Apps
November 07, 2026
My last post leaned hard on the DB-Engines ranking, and I admitted that ranking measures popularity, not installed base or revenue. Several of you called me on that, politely and otherwise. Fair enough. So this time I went looking for evidence that does not come from one ranking site. Usage surveys: where the money is going, what cloud vendors are building, and what AI tools reach for when nobody tells them what to use.
My conclusion has not changed, but I think the case is much stronger than I made it out to be. Beyond DB-Engines The best usage number I can find comes from developers themselves. In the 2025 Stack Overflow Developer Survey, 55.6% of all respondents said they use PostgreSQL, up from 48.7% in 2024. Among professional developers it was 58.2%, roughly 18 points ahead of MySQL ( summary of the survey ). It also topped the admired and desired lists again.
That is still a survey, not an install count. But it is people saying "I use this," not people searching for it, and that is a different signal from the one DB-Engines measures. Three caveats on my own napkin math from last time: Straight lines lie. I projected the MySQL and Oracle crossovers assuming this year's pace continues indefinitely. Adoption usually follows an S-curve, so 2028 and 2029 are best read as "if nothing changes," which is never true. The scores are relative.
Some of the decline at the top is the whole relational category losing attention to Snowflake, Databricks, and DuckDB. Not every lost Oracle point is a PostgreSQL gain. Scales matter. Jeremy Schneider pointed out in the comments that the log-scale chart flattens the story. He is right. On a linear scale the gap between PostgreSQL and the others closes visibly faster. Follow the money Last time I wrote that big data and AI vendors have been buying PostgreSQL companies, and I did not name them. Here they are.
Date Buyer PostgreSQL company Reported price
Oct 2025 Investors (Accel, Peak XV) Supabase, $100M Series E $5B valuation ( Orrick )
Jun 2025 Snowflake Crunchy Data about $250M, unconfirmed ( TechTarget )
May 2025 Databricks Neon about $1B ( TechTarget ) Supabase was valued at $2B in April 2025 and $5B six months later. Snowflake and Databricks are the two companies most often named as the threat to the relational leaders, and both decided they needed PostgreSQL in house. The more telling detail is what the incumbents sell. Every one of PostgreSQL's top-four rivals has an owner that also sells PostgreSQL: Oracle runs OCI Database with PostgreSQL , and Oracle's own MySQL blog has published a post on why you should move PostgreSQL to OCI.
Microsoft announced Azure HorizonDB , a new cloud-native PostgreSQL engine, at Ignite 2025, alongside Azure Database for PostgreSQL. Microsoft is also one of the larger corporate contributors to PostgreSQL itself. Amazon , which owns no top-four database but runs the biggest cloud, sells RDS, Aurora and the distributed Aurora DSQL , all PostgreSQL-compatible. When the companies you are supposedly beating are building products on you, you are doing something right. The protocol may be winning bigger than the database Here is something DB-Engines cannot see: many databases that are not PostgreSQL now pretend to be PostgreSQL.
CockroachDB, YugabyteDB, Google AlloyDB, the PostgreSQL interface on Google Spanner, Aurora DSQL, Materialize and RisingWave all speak the PostgreSQL wire protocol and some flavor of its SQL dialect. That matters because it means psql , JDBC, and every PostgreSQL driver, ORM, and GUI tool already work with them. (Yes, that includes DBeaver.) A new database vendor in 2026 picks PostgreSQL compatibility for the same reason a new laptop picks USB-C. It is where the users and the tools already are. In the 1990s, "SQL" became the common interface for relational databases.
PostgreSQL's dialect and protocol are becoming the common interface for this generation. That is a form of winning that never shows up as a PostgreSQL score. AI agents already made their choice I said last time that pgvector makes PostgreSQL a reasonable default for vector search. That undersells it. The bigger story is who is choosing the database. When Databricks bought Neon, it said more than 80% of the databases on Neon were being created by AI agents, not people ( TechTarget ). The "vibe coding" app builders mostly reach for Supabase, which is PostgreSQL underneath.
Ask a coding assistant to build you an app with a database and see what it picks. That is a pipeline. Every one of those prototypes that turns into a real product brings PostgreSQL with it, and nobody had a meeting about it. And for those who say PostgreSQL is fine until you get big: in January 2026, OpenAI described running ChatGPT's core database on a single-primary Azure PostgreSQL server, with nearly 50 read replicas across regions, serving 800 million users and millions of queries per second ( VentureBeat ).
It took a lot of careful engineering, but "not big enough" is a hard argument to make after that. Answering my own objections Last time I listed the obstacles in PostgreSQL's way. Several of them have better answers than I gave. "The community moves slowly." The core does, and on purpose. But the extension API means a lot of innovation never has to wait for a core release. pgvector, TimescaleDB, Citus, PostGIS, ParadeDB and pg_duckdb all ship on their own schedules. A slow core with a fast edge is a pretty good design.
"The installed base of Oracle and SQL Server code is huge." True, but the bridges keep getting better. Babelfish lets PostgreSQL understand T-SQL and the SQL Server wire protocol. Ora2pg and orafce handle much of the Oracle grunt work, and cloud vendors give away migration tools because they want the workload. None of it is magic, but rewriting PL/SQL is a smaller job than it was five years ago. "A free Oracle or SQL Server would remove the cost argument." It would remove the easy one. But look at what happened to "free" and "open" elsewhere.
MongoDB moved to the SSPL, Elastic and Redis changed licenses, and HashiCorp went to the BSL. Each was the owner's right, and each surprised its users. PostgreSQL cannot do that, because nobody owns it. The license is short, permissive and not going anywhere. That is a feature you only appreciate after you have been burned. "The PostgreSQL 19 reverts look unpredictable." I said a CIO would see unpredictability. Let me argue the other side. The project shipped on a schedule with fewer features rather than shipping features it did not trust.
Most of us have lived through a vendor release that went out on the sales calendar with known bugs. And if AI tools are finding more bugs, the code being shipped is getting more scrutiny, not less. One more I missed entirely: a lot of PostgreSQL never shows up under its own name. Several Chinese national databases, including openGauss, KingbaseES and PolarDB for PostgreSQL, are built from PostgreSQL code. Data-sovereignty concerns in Europe push the same way. Those users rarely search for "PostgreSQL," so the rankings undercount them. The other side of the ledger To be fair to the rest of the field: MySQL is everywhere.
Decades of LAMP stacks, WordPress sites and SaaS back ends do not migrate because of a survey. MySQL's installed base will outlast many of us. SQLite is the most deployed database on the planet. It is in your phone, your browser and probably your car. "Winning" depends on what you count. Analytics is moving somewhere else. Lakehouse platforms are taking the big analytical workloads that used to live in Oracle and SQL Server. PostgreSQL is winning the operational database fight, which is not the whole data fight. Oracle and SQL Server still own the most demanding enterprise systems.
RAC, Exadata and the deep SQL Server tooling are real, as Ludovico Caldara reminded us in the comments. So, is it winning? Yes, and by more than one ranking shows. Developers say they use it more than anything else. The money is buying PostgreSQL companies. The competitors' owners sell it. New databases copy its protocol. And the AI agents writing tomorrow's apps pick it without being asked. What I said last time still holds: popularity is not dominance, and the hard part is the installed base. But the trend is not one site's search-volume math. It shows up everywhere I looked.
I will check back after PostgreSQL 19 ships on November 19 and the December DB-Engines numbers come out. If you have data I missed, the comments are open. Sources Is PostgreSQL Really Winning? , the first post Stack Overflow 2025 survey: PostgreSQL results (third-party summary) Databricks adds Postgres database with $1B Neon acquisition , TechTarget Snowflake acquisition of Crunchy Data adds Postgres database , TechTarget Supabase raises $100M Series E at $5B valuation , Orrick How OpenAI is scaling PostgreSQL to 800 million users , VentureBeat OCI Database with PostgreSQL , Oracle Azure HorizonDB , Microsoft Tech Community Aurora DSQL FAQs , AWS
Comments
Post a Comment
Popular posts from this blog
Is the future of MySQL PostgreSQL (Or MariaDB, or TiDB, or ...)?
January 25, 2026
I am not intentionally trying to upset anyone with this blog post or minimize the efforts of many brilliant people whom I admire. However, I connected with several people over the 2025 holidays who all had the same question: What is the future of MySQL? At the upcoming FOSDEM conference, several events will discuss this subject and push a particular solution. And in several ways, they are all wrong. Oracle has not been improving the community edition for a long time now.
They have laid off many of their top performers in the MySQL group. We got almost a good decade and a half out of Oracle's stewardship of the "world's most popular database", and we should be thankful for that. However, now that time is over, it is time to consider future options that will involve no updates, CVEs, or innovation for what is the MySQL Community Edition. There are several choices available. Nothing! The first choice is nothing. Many folks run old, end-of-life versions of MySQL. There ...
Read more
How PostgreSQL's Aggregate FILTER Will Spoil You
February 22, 2025
Using PostgreSQL will definitely spoil you. I recently had to use another database and found, to my chagrin, that aggregate filters were not included in their implementation of Structured Query Language. Specifically, there was no FILTER clause available.
FILTER? To illustrate my dependency, let me start with some simple data. demo=# create table z (a int, b int, c int); CREATE TABLE demo=# insert into z values (1,10,100),(2,20,200),(3,30,300),(4,40,400); INSERT 0 4 demo=# select a,b,c from z; a | b | c ---+----+----- 1 | 10 | 100 2 | 20 | 200 3 | 30 | 300 4 | 40 | 400 (4 rows) demo=# If I wanted the overall number of rows, I could use a simple COUNT(*).
If I wanted an overall number of rows where one of the columns was of a certain value, I could add the logic for getting those rows to the WHERE clause. What if I wanted both? Do I need two queries to do the work separately? Maybe a materialized view or a CTE (Common Tabl...
Is PostgreSQL Really Winning?
November 03, 2026
The November 2026 DB-Engines rankings are out. PostgreSQL is the only database in the top four whose line is going up and to the right. Oracle, MySQL and Microsoft SQL Server all lost points this month, and all three are down from a year ago. PostgreSQL gained points on both counts. It now sits just 3.84 points behind SQL Server for third place. On the past year's trend, PostgreSQL could move ahead of SQL Server as early as next month. So it's time to celebrate, right? Maybe not yet.
Before anyone orders the cake, let's look at what the numbers say, why people are moving, and how hard the next step up will be. The numbers Only PostgreSQL gained points this month, and only PostgreSQL is up from a year ago. Source: DB-Engines Ranking of Relational DBMS , November 2026. A little napkin math shows when the order could change: SQL Server: The gap is 3.84 points. At this month's pace, it closes in about two months. At the past year's pace, it closes in less than one. S...
Fonte: Planet PostgreSQL
Highlights
- Stack Overflow 2025: 55,6% dos desenvolvedores usam PostgreSQL, 18 pontos acima de MySQL
- Databricks pagou US$ 1 bilhão pela Neon; Snowflake comprou Crunchy Data por US$ 250 milhões
- Supabase saltou de US$ 2 bilhões para US$ 5 bilhões em seis meses
- OpenAI roda ChatGPT com 800 milhões de usuários em PostgreSQL único com 50 réplicas
- CockroachDB, YugabyteDB e Aurora DSQL copiam protocolo PostgreSQL para compatibilidade
Este artigo foi escrito por Roberto Diniz, colunista de banco de dados. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Como fazer upgrade major do PostgreSQL sem downtime em um cluster distribuído
Um teste publicado pela pgEdge em 5 de novembro mostra como atualizar um nó de PostgreSQL 17 para 18 sem copiar o banco inteiro, usando as outras réplicas do cluster multi-master para segurar a aplicação enquanto o nó some por alguns minutos.











