The database that refused to die: How Postgres survived its own creators

Jump to main content

Search

REG AD

DATABASES

The database that refused to die: How Postgres survived its own creators

From academic toss-aside to cloud substrate

Joab Jackson

Joab<br>Jackson

Published<br>mon 22 Jun 2026 // 18:43 UTC

FEATURE Today Postgres is one of the most widely used database systems, but its launch and subsequent development were inauspicious to say the least.<br>If it weren’t for a league of exceptionally devoted open source contributors, it probably would be another forgotten also-ran just like Ingres, the database system on which it was based (“Postgres” was shorthand for “Post-Ingres”).<br>The creator of both systems, Michael Stonebraker, is perhaps the preeminent database pioneer in the field. Earlier this month, he spoke at PGDay, a conference in Boston hosted by the U.S. PostgreSQL Association, where he detailed the complicated history of the open source database system, which actually existed long before the term "open source" was even uttered.

REG AD

REG AD

In a sense, “Postgres is the epitome of open source software, because it doesn't belong to anybody. It was picked up by this team of programmers without any specific affiliation,” Stonebraker said.<br>Stonebraker essentially abandoned Postgres in the mid-1990s. But instead of fading into obscurity, the codebase was salvaged by a fiercely-dedicated volunteer community that bolted on standard SQL while preserving Stonebraker’s revolutionary extensible architecture.<br>Three decades later, this stubbornly-independent database has become the bedrock of modern cloud infrastructure.<br>Data should be relational<br>When it comes to relational database systems, British computer scientist and then-IBM employee Ted Codd got the ball rolling in 1970. A database is where you store your data so it can be queried in a predictable way. A database system is the software that manages the database (don’t confuse the two).<br>That year, Codd decreed that all data should be stored in tables and accessed using a high-level query language. IBM implemented Codd’s idea in System R, and created SQL as the query language. The results were eventually rolled into IBM's DB2.<br>Stonebraker, then an assistant professor at UC Berkeley, also implemented Codd’s ideas. Stonebraker and his team of grad students created not only a working prototype, but a full-scale implementation – he later cofounded a startup, Relational Technology, to sell Ingres commercially. Ingres did not use SQL, but instead employed another query language, QUEL (Query Language), although the fundamentals were similar.

MORE CONTEXT

The new database world according to Google: Inexact queries and AI in everything

SQL Server may be too lucrative for Microsoft to ditch, but too legacy to love

PostgreSQL backup tool gets some backup of its own after sole maintainer sounds alarm

IBM asks DBAs to trust AI to act on their behalf

A relatively primitive version of Ingres was even released gratis for academic research. But by the early 1980s, Stonebraker had “pushed the code off a cliff” and started building something new.

REG AD

Thus, Postgres was born.<br>Beyond Ingres: Postgres<br>At the time, Stonebraker explained, the business world was pushing for databases to hold additional data types beyond the integers, floats, and character strings required for basic business accounting. There was complicated CAD data and GIS data, with multiple data points that needed to be stored and reasoned against.<br>It was clear to Stonebraker and his colleagues that the ideal database system needed to be extended with more data types, user-defined data types, user-defined operators, and user-defined functions.<br>Adding more data types and such might seem simple enough, but the “devil is in the details,” he noted. “You need to be able to teach the query optimizer about new types, and that's not exactly easy.” Commutative rules had to be worked out, and they had to be optimized.<br>This led to what was probably Postgres’ most successful feature: support for abstract data types (ADTs).<br>Stonebraker had other ambitions for Postgres as well. He also wanted to incorporate new work from Chris Date on referential integrity, which brought “semantic consistency between foreign keys and primary keys” to the relational model. He wanted to add in a rules engine, which would continually monitor for changes and make decisions based on those changes. Also, he wanted crash recovery.<br>The crash recovery and the rules engine never quite worked out, but the ADTs took root, and now most database systems support this extensibility, pretty much exactly like they were devised by Stonebraker and Co. in 1983.

REG AD

“We pretty much got it right,” he said. In fact, he reckons that his work on ADTs was probably the major reason he landed the Association for Computing Machinery’s 2014 A.M. Turing Award.<br>Stonebraker and his mates were eager to make money from their creation. So they rolled...