Number Research
← Back to Explore
Information Systems Software Development Open Source Database History

The Database That Refused to Become a Product

POSTGRES spent the dot-com boom as an also-ran; two design choices from 1986 made it the world's most-used database by 2024.

S.J. Nam 7 min read

In 1986, in a lab at the University of California, Berkeley, a professor named Michael Stonebraker started building a database that wouldn't win for another thirty-seven years. He already had a hit — Ingres, the relational system that helped prove Edgar Codd's theories could run on real hardware. POSTGRES, the "post-Ingres" project, was the sequel, funded by an unglamorous coalition of DARPA, the Army Research Office, the National Science Foundation, and a defense contractor called ESL, Inc. It was slow. It didn't even speak SQL. And for most of the next two decades, it lost.

Then, in Stack Overflow's 2023 developer survey, PostgreSQL passed MySQL to become the most-used database on Earth. In 2024 it did it again, with nearly half of all surveyed developers reaching for it — the most popular, most admired, and most wanted database, for the second consecutive year. DB-Engines named it the DBMS of the Year for 2023. The academic experiment that spent the dot-com boom as an also-ran is now the default.

The tidy explanation is that Postgres is reliable, free, and feature-rich, so it won on merit. That's true and it's boring, and it misses the actual mechanism. Postgres endures for a stranger reason: it was designed from the start not to be a finished product, and it is governed by no one who could turn it into one. Its two supposed weaknesses — an academic obsession with extensibility and the total absence of a corporate parent — are exactly why it outlasted everything built to beat it.

Stonebraker's Long Bet

Most databases of the 1980s asked a narrow question: how do we store rows and columns and query them fast? Stonebraker's team asked a weirder one. What if the database didn't know, in advance, what kinds of data it would ever hold — and users could teach it new types, new operators, new indexing methods without touching the core engine? That idea, the "object-relational" model, is the reason the initial POSTGRES was heavy and academic. It carried machinery that early rivals could mock as overengineering.

It also carried the future. The bet was that a database is not a product with a fixed feature list but a platform whose capabilities its users extend. When developers a generation later wanted to store JSON documents, geospatial coordinates, full-text search indexes, time-series data, or the high-dimensional vectors that power modern AI retrieval, they didn't have to wait for a vendor's roadmap or migrate to a specialized system. Someone wrote an extension. PostGIS turned Postgres into arguably the world's most capable open geospatial engine; pgvector turned it into a credible vector store for machine-learning embeddings almost as soon as the demand appeared. The core barely changed. That is the payoff on a design decision made when the personal computer was a novelty.

There's a quieter piece of this history that almost no coverage mentions. The project's engineers built POSTGRES to conform to POSIX, the Unix portability standard — a choice that sounds like plumbing and turned out to be destiny. It meant Postgres could run more or less anywhere Unix ideas reached, which by the 2010s meant everywhere. Ubiquity that looks like luck was, in part, a standards decision buried in the 1980s. The system also came late to the lingua franca of databases: it wasn't until 1994 that Andrew Yu and Jolly Chen bolted an SQL interpreter onto the Berkeley code, producing "Postgres95," renamed PostgreSQL in 1996 and versioned at 6.0 to honor the original project's lineage. Postgres reached the industry standard nearly a decade after commercial rivals had staked their claim to it. Being late did not kill it. The architecture underneath was patient enough to wait.

The Virtue of Having No Owner

Here is the counterintuitive heart of the thing. MySQL, the rival Postgres finally overtook, had everything Postgres lacked in the 2000s: momentum, marketing, a snug fit in the LAMP stack that powered the first web boom, and eventually a corporate steward. That steward became Oracle. And a corporate owner is a mixed blessing — it can fund development and steer the roadmap, but it can also acquire, neglect, relicense, or quietly point the open version toward its own paid cloud.

Postgres cannot be acquired, because there is nothing to buy. It's released under the PostgreSQL License, a permissive BSD/MIT-style license, and stewarded by the PostgreSQL Global Development Group — a volunteer association of contributors and companies with no single corporate owner and no one who controls the roadmap. Decisions run through consensus among core contributors. The community has a blunt phrase for what this buys you: "no single throat to choke." It sounds like a disadvantage. Who do you call when it breaks? But for anyone planning on a ten-year horizon, ownerlessness is the feature. The companies that pour engineering into Postgres — EnterpriseDB, Crunchy Data, Microsoft, Amazon, Google, and the rest — compete to build atop it precisely because none of them can capture it.

Watch what happens to permissive open-source projects that do have owners. Over the past several years a string of them — in databases, search, and infrastructure — abruptly changed their licenses to fend off cloud giants reselling their work, stranding users who'd built on a promise of openness. Postgres has never faced that temptation, because there's no shareholder to satisfy and no exit to engineer. The Global Development Group states plainly that it intends to keep Postgres free and open in perpetuity. A project that can't be sold can't be betrayed.

Why Boring Won

The deep irony of PostgreSQL's ascent is that it violates the usual story of how technology wins. We expect the victor to move fast, break things, and be pushed by a company with everything to gain. Postgres moved slowly, broke almost nothing, and was pushed by nobody in particular. It ships one major release a year on a metronome — version 18 arrived in September 2025 — and its reputation is built on the least fashionable virtues in software: correctness, durability, and not losing your data.

That temperament is precisely what compounds. Every year a specialized database launches to solve one problem better than Postgres does — and every year Postgres absorbs a version of that capability as an extension and keeps the rest of the developer's stack in one place. The specialists have to win on their single axis forever. Postgres only has to be good enough on many axes while remaining the thing you already run. Stonebraker's 1986 wager was that generality, patiently maintained, beats specialization over a long enough clock. Four decades later the survey numbers are the proof, and the lesson runs against the grain of nearly everything the industry tells itself about how to build lasting software: the database that won is the one that refused to become a product, owned by no one, in a hurry to go nowhere.

References