Is PostgreSQL Really Winning?

 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. So a December 2026 or January 2027 crossover is realistic.
• MySQL: The gap is 133.54 points. Over the past year, the gap shrank by about 81 points. If that keeps up, PostgreSQL passes MySQL around mid-2028.
• Oracle: The gap is 406.46 points. Over the past year, it shrank by about 182 points. That points to early 2029.

The long-term chart tells the same story. PostgreSQL climbed from roughly 200 points in 2013 to almost 700 today. Over the same years, the top three slowly drifted lower. Further down the list, MariaDB has slipped since its 2022 peak.

One caveat: DB-Engines measures popularity, not installed base or revenue. The score comes from search interest, job postings, Stack Overflow questions, social media mentions, and similar signals. A rising score shows that people are talking about PostgreSQL, learning it and hiring for it. That isn't the same as running more production workloads on it.

Why people are leaving the expensive databases

The short answer is money, but money is not the whole story. These are the reasons I hear most often from people making the move:

• Licensing pain. Per-core licensing, audits, virtualization rules, and support contracts that go up every year all make finance teams look for the exit. Many shops moved to PostgreSQL after one too many audits.
• The cloud changed the math. Every major cloud offers managed PostgreSQL, and several sell their own PostgreSQL-compatible engines. If you're already moving to the cloud, PostgreSQL is the database that comes with no license fee.
• No vendor lock-in. Nobody owns PostgreSQL. You can run it on-premises, in any cloud, or with any of dozens of support vendors, and switch between them. CFOs and CTOs both like that kind of freedom. Of course, your cloud provider may be offering their own special PostgreSQL brew laced with special them-only features.
• It's good enough for most work, and often better. JSONB, solid replication, partitioning, and a huge extension ecosystem (PostGIS, pgvector, TimescaleDB, Citus) cover workloads that used to need a commercial product.
• Talent and momentum. New developers learn PostgreSQL first. Startups default to it. Big data and AI vendors have been buying PostgreSQL companies. When a skill is everywhere, hiring is easier and cheaper. Beware, as some of the AI (I am looking at you ChatGPT) are not trained on the last few versions of PostgreSQL and simeple do not know about things like JSON_TABLE() and other recent additions.
• AI workloads. pgvector made PostgreSQL a reasonable default for vector search. Many teams would rather keep embeddings next to their relational data than add another database.

Free as in free puppy

Open source people like to talk about "free as in beer" and "free as in speech." PostgreSQL should also be thought of as free as in free puppy. Taking it home costs nothing. Taking care of it for the next fifteen years is a different story. (I heard Kellyn Gorman say the puppy analogy was from one of her coworkers but I missed their name).

You are trading license fees for other costs:

• People. Someone has to tune vacuum, plan major-version upgrades, manage connection pooling, and watch for transaction ID wraparound. Experienced PostgreSQL DBAs are in demand and are not cheap. BTW, cheap DBAs are not always the bargain your hiring manager and HR desire. 
• Tooling. Backup, high availability, monitoring, and failover often involve selecting and integrating several separate projects, such as Patroni, pgBackRest, and PgBouncer. Commercial databases include much of this in the box. Like Legos, you have to put the pieces together, and they need you to do so. 
• Support. When something breaks at 2 AM, you need a support contract, a managed service, or a very good team. All three cost money.
• Migration. Moving off Oracle or SQL Server means rewriting PL/SQL or T-SQL, retesting applications, and retraining staff. That bill comes before you save anything.

None of this means PostgreSQL is a bad deal. For most organizations, the puppy is worth it. Just budget for the food, the vet, and the chewed-up shoes before you bring it home.

The fly in the ointment: PostgreSQL 19's reverts

PostgreSQL 19 is late, and it lost several of its biggest features during the beta. Usually a new major version comes out between mid-September and mid-October. PostgreSQL 19 is now scheduled for November 19, 2026, about a month behind the usual schedule (Robert Haas on the delay).

These are the features that were pulled during the beta:

Date (2026)	Feature reverted	Reason given
Sep 16	Online data checksum transitions	"To avoid shipping code which may have bugs"
Sep 15	UPDATE/DELETE FOR PORTION OF (temporal tables)	Not stated
Sep 13	pg_get_role / tablespace / database_ddl functions	Not stated
Sep 11	Two CREATE SCHEMA changes	Compatibility breakage outweighed the gain
Sep 10	Identifier casefolding change	Unintended behavior change with certain locales
Sep 7	SQL/PGQ property graph queries (47 commits)	Not stated
Late Aug to mid Sep	ALTER TABLE … MERGE / SPLIT PARTITION	Not stated

Sources: Command Prompt, Robert Haas.

SQL/PGQ graph queries were supposed to be the headline feature. Losing it a few weeks before release is a rough look for a project that wants the enterprise market.

There's another way to read this, though. Haas argues that the cause is "LLMs happened." AI tools have made it "vastly easier to find those bugs." He says back-patched fixes rose more than 60% from the year before, and that work took committer time away from finishing new features. In his words, the delay "emerges directly from the project's concern for quality."

I agree with that. A project that pulls a feature it isn't sure of is behaving responsibly. But to a CIO comparing PostgreSQL with Oracle or SQL Server, a late release with its headline features removed looks like unpredictability. Perception matters, and so do rankings.

The climb gets harder from here

Passing SQL Server would be a milestone, but each step above it is steeper. These are the challenges I see ahead:

• The installed base is huge. Decades of Oracle and SQL Server applications, many of them packaged ERP systems, aren't moving soon. Some vendors simply don't certify on PostgreSQL.
• The community model is slow. PostgreSQL has no single company setting priorities. A small group of committers reviews everything. That protects quality, but big features can take years and may still get pulled, as PostgreSQL 19 showed.
• Committer bandwidth is limited. If AI-assisted bug hunting keeps finding more problems, the same people have to fix them. That leaves less time for new work.
• The ecosystem is fragmented. "PostgreSQL" can mean community PostgreSQL, Aurora, AlloyDB, Azure Database for PostgreSQL, or a dozen compatible forks. That's a strength for adoption, but it divides engineering effort and confuses buyers about what they're actually getting.
• Operational gaps remain. Built-in high availability, easier major-version upgrades, and better tooling for very large databases still need add-ons. Commercial competitors use those gaps as selling points.
• The scores are relative. DB-Engines scores depend partly on how much the others are discussed. As newer platforms like Snowflake, Databricks and DuckDB draw attention, everyone has a harder time gaining points.

How the leaders could fight back

The three databases above PostgreSQL are losing points, but they aren't out of options.

Oracle could make price a smaller reason to leave. Simpler licensing, a more generous free tier, or real price cuts on its cloud would do it. It could also promote what PostgreSQL still lacks: RAC-style clustering, mature built-in tooling, and one company that answers the phone. Oracle is already well positioned in AI, with vector search and converged-database features. Pushing that story harder would help.

MySQL has the easiest comeback story and the most to lose. Its open source community has grown impatient with how slowly features land in the Community edition. If more new work went into the open-source release rather than HeatWave, and the community saw a clear roadmap, MySQL would win back goodwill. Its strengths are still real: simple operation, a huge installed base, and a familiar name.

SQL Server is the one PostgreSQL is about to pass. Microsoft's best counter is integration. SQL Server already works smoothly with Azure, Fabric, Power BI, Entra, and Copilot. The pitch is that it costs more, but everything just works. Microsoft could also bundle more aggressively, for example with Azure credits or price breaks for Microsoft 365 shops. Microsoft also sells a lot of managed PostgreSQL on Azure, though. It may not mind much if its customers move from one Microsoft-hosted database to another.

All three can also use PostgreSQL's free puppy problem against it. They can emphasize the total cost of ownership and the risk of piecing together a stack of open-source tools.

What if the price went to zero?

I am still a huge fan of PostgreSQL, and I sincerely hope it becomes the database of choice. But what if Oracle and Microsoft decided that the way to beat the open-source bandwagon is to greatly cut, or even eliminate, license costs? Can PostgreSQL still compete?

It's not as far-fetched as it sounds. Both companies already offer limited editions, such as Oracle Database Free and SQL Server Express and Developer. Microsoft makes more and more of its money from Azure compute, storage, and services, not from license keys. A free SQL Server that drives Azure consumption would fit its business model. Oracle depends much more on license and support revenue, so a deep cut would hurt it more. But Oracle has changed course dramatically before.

What PostgreSQL would lose

• Its easiest argument. For many shops, cost is the main reason to migrate. Take cost out of the equation, and a long, risky rewrite of PL/SQL or T-SQL becomes much harder to justify.
• New migrations would slow down. Legacy applications already running on Oracle or SQL Server would have even less reason to move.
• Enterprise features would compete on equal terms. RAC, built-in high availability and polished management tools at little or no cost would show PostgreSQL's operational gaps more clearly.

What PostgreSQL would keep

• Free means more than price. The PostgreSQL License can't be revoked, repriced, or audited. A free proprietary license is free only until the vendor decides otherwise. Anyone who went through Java licensing changes or VMware's post-acquisition repricing remembers that.
• No single owner. You can run PostgreSQL anywhere, with anyone's support, and move whenever you like. A zero-cost license doesn't remove lock-in to a vendor's cloud, roadmap, and support terms.
• The ecosystem. Extensions like PostGIS, pgvector, TimescaleDB and Citus, plus every PostgreSQL-compatible cloud service and fork, can't be matched by a price cut.
• Developer mindshare. A generation of developers learned PostgreSQL first. Startups that build on it today become the enterprises of tomorrow.
• Trust. Decades of audits and contract negotiations left scars. Many customers would assume free is just bait for the next upsell, and some would be right.

The verdict

Yes, PostgreSQL can still compete, but the argument would change from cost to value. The free-puppy argument would apply to commercial vendors, too. They would still make money somewhere, through support, cloud consumption, or premium features. PostgreSQL's answer would have to be what open source does best: freedom, portability and community. It would also need to close the gaps that matter to enterprises: built-in high availability, easier upgrades and predictable releases. A free Oracle or SQL Server wouldn't end PostgreSQL's growth, but it would end the easy part.

So, is PostgreSQL really winning?

It's winning the trend, but it hasn't won yet. It's the only top-four relational database that is gaining popularity, and it will probably take third place within a month or two. The reasons people are moving are real: cost, freedom from lock-in, the cloud, and a strong feature set.

Still, being popular isn't the same as being dominant. PostgreSQL 19's late, trimmed-down release shows the limits of a volunteer-driven community model. The free puppy still needs feeding, and the databases above it have deep pockets and loyal customers.

My take: watch next month's rankings for the SQL Server crossover. Then watch whether PostgreSQL 19 ships cleanly on November 19 and whether the reverted features return in PostgreSQL 20. Those will say more about PostgreSQL's next five years than any single month's score.

Sadly, in many decades of experience, I have seen too many good products snatch defeat from the jaws of victory at the very last minute.  

Sources

• DB-Engines Ranking of Relational DBMS, November 2026
• Robert Haas: Postgres 19 is late, and it's AI's fault
• Command Prompt: 6 Reverts for PostgreSQL 19

Note: The methodology of the engine ranking has long been matter of discussion for many. I like to use it as one point of view. Like IQ tests or the DJIA, there are lots of problems with relying just on that one measure. It is a handy, albeit simple, benchmark and should not be used other than a reference point among many in any decision you make.