PostgreSQL : How an Open-Source Database Conquered the World

For the third consecutive year, PostgreSQL is the most used, most loved, and most desired database on earth. Its share of professional developers has hit 55.6% — a seven-point jump in a single year that represents the largest annual expansion in its history. This is the story of how a university research project became the undisputed king of the database world — and why it shows no signs of stopping.

There is a particular kind of victory in the technology industry that is harder to achieve than any product launch or funding announcement. It is the victory of becoming the default — the answer that developers reach for without deliberating, the technology so entrenched in the mental model of an entire profession that choosing something else requires a justification. PostgreSQL has achieved that victory in the database world, and the latest data confirms the scale of the achievement in terms that permit no ambiguity.

The 2025 Stack Overflow Developer Survey — the closest thing the software industry has to a census, drawn from 49,000+ developers across 177 countries — delivered a verdict on the database landscape that is as clear as any data point in the survey’s history. PostgreSQL is used by 55.6% of professional developers, up from 48.7% the previous year. It is the most admired database, with 65% of its users wanting to continue using it. It is the most desired database, with 47% of all developers wanting to work with it next year. And it has held all three of these titles simultaneously for the third consecutive year — a hat trick that no other database has ever achieved.

The numbers capture the outcome of a transformation that has been building for years but has only become fully legible in the current data. PostgreSQL is no longer one of the popular databases. It has opened a 15-point gap over MySQL, its closest competitor. It has made Oracle and SQL Server look like legacy holdovers from a previous era. And it has absorbed the ecological niches of MongoDB, Redis, InfluxDB, and half a dozen other specialist databases — not by copying what they do, but by extending its own architecture to do those things better.

The Numbers: A 15-Point Gap and a Third Consecutive Triple Crown

The database adoption data from the 2025 Stack Overflow survey makes for striking reading, particularly when viewed in year-over-year comparison:

Three patterns stand out from the table. First, PostgreSQL’s growth is accelerating — not plateauing. A 6.9-percentage-point increase in a single year is the largest in its history, and it comes on top of already-dominant market position. Second, every major competitor except SQLite is losing share. MySQL, Oracle, SQL Server, MongoDB, and Redis have all declined. The database world is not simply growing, with different databases claiming different slices — it is consolidating around a single answer. Third, and most strategically significant: the most desired database (47%) trails the most used database (55.6%) by only 8 points. This means PostgreSQL is not merely inherited through inertia — it is actively chosen by developers who have the opportunity to choose something different.

The survey drew data from 49,000 developers across 177 countries. The professional developer subset — those working in software as their primary occupation — shows an even stronger PostgreSQL dominance than the overall numbers. For this population, PostgreSQL is not just the plurality choice; it is the majority choice. More than half of all professional developers worldwide are working with PostgreSQL on a daily basis.

“PostgreSQL has achieved a three-peat as the undisputed champion across all three database metrics for the third consecutive year. The database world is in the process of unification and convergence. Based on the past nine years of trends, nothing can shake this anymore. Ecologically, PostgreSQL has become the hegemon of the database world.”

— Vonng (Database Veteran Analysis), 2025 Stack Overflow Survey Review

How We Got Here: Four Decades from Berkeley to Global Default

PostgreSQL’s ascent was not fast. It was the accumulation of forty years of principled engineering decisions that only became fully visible in their consequences around 2018 — the moment when the extension ecosystem hit critical mass and the database transformed from an excellent relational database into something closer to a universal data platform.

The 2023 inflection point deserves particular attention. Before 2023, PostgreSQL and Redis had competed neck-and-neck for the “most loved” title for six consecutive years. Both sat around 70% admiration ratings — an extraordinary result for any technology, but not a decisive one. Then Redis took a significant plunge in the 2023 survey, dropping to fourth-most-loved behind SQLite, Valkey, and PostgreSQL. The causes are debated, but the timing coincides with Redis’s controversial licence change from open-source to a more restrictive commercial licence — a decision that damaged community trust significantly.

PostgreSQL, by contrast, has maintained its fully permissive PostgreSQL Licence since 1996. It has never been acquired by a commercial entity. It has never changed its licensing terms. It has never introduced paid enterprise tiers for core functionality. The trust that developers place in PostgreSQL is partly earned through the software’s technical qualities and partly earned through decades of institutional behaviour that has never asked the community to pay a price for its loyalty.

Why PostgreSQL Won: The Six Reasons That Together Are Decisive

1. Uncompromising Correctness as a Foundation

PostgreSQL’s foundational commitment is to do what it says it will do, completely and reliably. It enforces ACID (Atomicity, Consistency, Isolation, Durability) guarantees without exception. It adheres to the SQL standard more strictly than any other relational database. It does not silently truncate data that doesn’t fit a column type. It does not accept invalid dates or allow null constraints to be violated quietly.

This sounds like a baseline expectation — but for years, MySQL was the dominant alternative, and MySQL’s default configuration violated most of these properties. MySQL’s default storage engine did not enforce foreign key constraints. Its date handling was notoriously permissive. Many MySQL configurations quietly accepted data corruption rather than returning an error. Developers who switched from MySQL to PostgreSQL frequently described the experience as discovering that their database had, all along, been silently accepting data it should have rejected.

2. The Extension Model: A Platform, Not Just a Database

The architectural decision that has done more to drive PostgreSQL’s dominance than any single feature is the extension model — designed by Michael Stonebraker into the original POSTGRES architecture in the 1980s. PostgreSQL can be extended with new data types, new index types, new operators, new procedural languages, and new storage engines without modifying the core database code. This extensibility is what enabled the explosion of specialist extensions that now make PostgreSQL a genuinely multi-purpose platform:

The pgvector extension deserves special mention in the current moment. As AI applications have moved from experimental to production, the need to store and query vector embeddings — the mathematical representations of text, images, and other data used by machine learning models — has become one of the most common new infrastructure requirements in software development. A generation of specialized vector databases (Pinecone, Weaviate, Qdrant, Chroma) emerged to serve this need. pgvector means that for many applications, PostgreSQL can serve this need too — in the same database where the rest of the application data lives, with the same backup and recovery tools, under the same operational procedures.

3. JSON/JSONB: Winning the NoSQL Arguments from Within

The great database debate of the 2010s was SQL versus NoSQL. Startups reaching for MongoDB argued that document databases offered the schema flexibility that relational databases could not provide — the ability to store heterogeneous, nested data structures without defining a rigid schema in advance. For a period, this argument was compelling enough that MongoDB became the default choice for new web applications, and the debate felt genuinely open.

PostgreSQL’s introduction of JSON support in 2012 and JSONB (binary JSON) in 2016 ended that debate. JSONB allows developers to store arbitrary JSON documents in a column, index any field within those documents using standard or custom index types, and query them using SQL expressions that are at least as expressive as MongoDB’s query language. The schema flexibility argument for NoSQL — the primary reason most teams chose document databases — is no longer a compelling distinction when your relational database can store and query documents natively.

The data from the 2025 Stack Overflow survey captures the consequence. Developers working with MongoDB and Redis show particularly strong desire to add PostgreSQL to their toolkit next year — the classic pattern of developers who have experienced the limitations of specialist tools and are now consolidating around a system that can serve multiple needs.

4. The Open-Source Trust Dividend

PostgreSQL’s community development model has consistently produced outcomes that proprietary and commercially-backed databases cannot replicate. With over 400 code contributors across more than 140 supporting companies — including Amazon, Google, Microsoft, EnterpriseDB, Pivotal, and dozens of others — the project benefits from corporate investment without being controlled by any single corporate interest. No single company can change PostgreSQL’s licensing terms, remove features from the open-source version, or prioritize the needs of paying customers over the needs of the community.

This matters most in the context of alternatives that have made different choices. MongoDB’s Server Side Public Licence change in 2018 fractured its community and spawned the DocumentDB forks. Redis’s commercial licence changes generated a community fork (Valkey) that now competes directly with the original product. Elasticsearch’s SSPL change prompted OpenSearch. In each case, a commercial decision about licensing created a permanent trust deficit in the affected community. PostgreSQL has never made that decision, and its licence history — permissive since 1996, unchanged through every change in the surrounding industry — is a form of institutional credibility that cannot be manufactured or purchased.

5. Cloud Hyperscaler Adoption as Distribution

When Amazon, Google, and Microsoft each independently decided to offer managed PostgreSQL-compatible services — Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL, Google Cloud SQL for PostgreSQL and AlloyDB, and Microsoft Azure Database for PostgreSQL and the Citus acquisition — they collectively became the distribution mechanism for PostgreSQL’s adoption at enterprise scale. These offerings removed the operational burden of running PostgreSQL in production, and in doing so, removed the last meaningful argument for choosing a commercially supported database like Oracle: that operational complexity required a vendor with a support contract.

The irony is that the hyperscalers’ PostgreSQL offerings have, in some cases, created tension with the community — Amazon’s Aurora PostgreSQL is based on PostgreSQL but modified in ways that are not fully open-source, prompting debate about the appropriateness of claiming PostgreSQL compatibility while withholding modifications. But for adoption purposes, the effect is unambiguous: managed PostgreSQL services from three of the largest technology companies in the world mean that any team wanting to use PostgreSQL in production has a fully supported path to do so without operational expertise.

6. The Default Flywheel: Tutorials, Tools, and Talent

Once a technology becomes the default choice for new projects, a self-reinforcing cycle begins. New developers learn it first because it is what the tutorials use. New tools are built to integrate with it first because it is what the users are running. New cloud services launch with PostgreSQL compatibility because it is what the customers ask for. New employees at established companies find PostgreSQL already installed because their predecessors chose it. The technology’s dominance becomes self-perpetuating because the switching cost of choosing anything else grows with every tutorial written, tool built, and hire trained.

PostgreSQL crossed the threshold into default status somewhere around 2021–2023, and the 2025 survey data reflects what happens once that threshold is crossed. The 6.9-percentage-point increase in a single year is not the result of millions of individual developers making independent decisions to switch — it is the consequence of PostgreSQL having become the path of least resistance for new projects, new teams, and new developers entering the field.

“It’s 2025, and if you’re a professional developer picking a database for a new project, there’s a damn good chance you’re reaching for PostgreSQL first. The database wars finally ended. PostgreSQL won.”

— Ankita Tripathi, Medium (Stack Overflow Survey 2025 Analysis)

PostgreSQL and the AI Era: The Database That Was Ready

One of the most consequential coincidences in recent technology history is that the rise of large language models and AI applications began at almost exactly the moment when PostgreSQL’s extensibility ecosystem hit critical mass. The AI wave of 2022–2026 created sudden, enormous demand for infrastructure that could store and query vector embeddings at scale — and pgvector, which had been in development since 2021, was ready.

For many AI application developers, the choice of vector database is now not a separate decision from the choice of primary database. If their application’s data lives in PostgreSQL — and with 55.6% adoption, it usually does — pgvector means the vector search capability lives there too. The RAG (Retrieval-Augmented Generation) pipelines that power most enterprise AI applications need to store embeddings, retrieve semantically similar chunks, and join the results with application metadata. In PostgreSQL with pgvector, that is a single query. In a system with a separate vector database, it requires a round trip, a data synchronization mechanism, and a consistency model.

Amazon’s introduction of Aurora Machine Learning and Google’s AlloyDB AI with columnar engine optimization both reflect the same bet from the hyperscaler side: that the future of AI infrastructure at scale will be built on PostgreSQL-compatible systems, not on separate specialist databases. The extension model that Stonebraker designed in 1986 is turning out to be the right architectural foundation for the AI era — not because he foresaw large language models, but because he understood that the most valuable property of a database platform is the ability to adapt to use cases that haven’t been invented yet.

The Honest Limitations: What PostgreSQL Still Gets Wrong

No honest analysis of PostgreSQL’s dominance should ignore its genuine limitations — not because they threaten its current position, but because they define the scenarios where the dominance is not absolute and the conditions under which alternatives remain compelling.

Connection handling is PostgreSQL’s most frequently cited structural weakness. PostgreSQL creates a separate operating system process for each connection, which means connection overhead is measured in megabytes rather than kilobytes. In applications that open many short-lived connections — typical of serverless architectures and microservice patterns — this can create significant resource pressure. The standard mitigation is PgBouncer or similar connection poolers, which work well but add operational complexity. Neon, Supabase, and other PostgreSQL-as-a-service providers have built significant infrastructure specifically to address this limitation at the platform level.

Write scalability at very high concurrency is a second area where alternatives can outperform PostgreSQL. For workloads requiring extremely high write throughput across distributed systems — particularly event-streaming applications and global distributed databases — systems like CockroachDB, YugabyteDB (both PostgreSQL-compatible), or Cassandra may offer architectural advantages. The nuance: both CockroachDB and YugabyteDB chose to be PostgreSQL-compatible at the protocol level, meaning the ecosystem they are competing in is defined by PostgreSQL’s interface.

The documentation and learning curve, though substantially better than a decade ago, remains steeper than MySQL’s for simple use cases. PostgreSQL offers more features, more configuration options, and more operational complexity than most applications need. For a developer standing up a simple web application for the first time, this can be intimidating. The thriving managed service ecosystem (Supabase, Neon, Railway, Fly.io) has done much to hide this complexity, but it remains real for teams operating PostgreSQL without managed infrastructure.

What Comes Next: The 2026 Horizon

Several developments in the PostgreSQL ecosystem are likely to sustain and extend its dominance over the next few years.

The Neon architecture — which separates compute and storage to enable serverless, instant-branching PostgreSQL — represents the most architecturally significant innovation in PostgreSQL hosting since managed cloud services. Neon allows database branches (exact copies of a database state, created instantly for development, testing, or preview environments) with the same semantics and tooling as git branches for code. If this pattern achieves mainstream adoption, it will resolve one of the most persistent friction points in PostgreSQL’s developer experience: the difficulty of managing multiple environments consistently.

The PostgreSQL 18 release cycle, currently in development, is focused on significant parallelism improvements, enhanced logical replication, and further JSON/JSONB capabilities. The community has also been working on incremental view maintenance — a long-requested feature that would allow materialized views to update incrementally rather than requiring full recomputation — which would significantly improve PostgreSQL’s performance profile for analytical workloads.

The valkey entrant noted in the 2025 survey data — scoring 64.7% as most loved database in its debut — is worth monitoring as the Redis fork matures. But its position at the top of the most-loved list alongside PostgreSQL suggests that the broader ecosystem is moving toward open-source, community-governed technologies and away from commercially-controlled ones. This is a trend that favours PostgreSQL structurally.

The Elephant That Ate the Database World

PostgreSQL’s mascot is Slonik the elephant — a grey, dependable creature famous for never forgetting and for moving with deliberate certainty. It is, in retrospect, an appropriate choice for a project that spent forty years building towards a dominance that looked, at each individual stage, like it might still be contested.

The 55.6% adoption figure in the 2025 Stack Overflow survey is not a temporary spike. It is the culmination of foundational correctness, architectural extensibility, community trust, licensing honesty, and timing that aligned PostgreSQL perfectly with the two biggest infrastructure shifts of the decade: the move to managed cloud services, and the explosion of AI applications requiring vector search capabilities. Each factor reinforced the others. The default flywheel is now spinning fast enough that reversing it would require a mistake of historic proportions — the kind of licensing change or commercial decision that PostgreSQL’s governance model structurally prevents.

Vonng’s analysis described this as unification of the database world — all roads leading to PostgreSQL. That may overstate the case for the very long run, where distributed systems and AI-native databases will continue to create new use cases that challenge any single-system answer. But for the generation of software being built today, on the cloud infrastructure of 2026, by the professional developers whom surveys can actually count — the database wars are over. PostgreSQL won.