Postgres survived a mid-1990s abandonment and became cloud infrastructure anyway

Postgres has a founder problem that turned into a founder win. Michael Stonebraker, the creator of both Ingres and its successor Postgres, essentially abandoned Postgres in the mid-1990s. And yet, in 1995, two Berkeley graduate students, Andrew Yu and Jolly Chen, resurrected it from the last 4.2 academic release, swapped out QUEL for SQL, removed features that were failing in practice (the rules engine and disaster recovery), and released it as Postgre95, later PostgreSQL.

That “walked away” moment is not trivia. It is the reason Postgres exists in the form decision-makers now rely on. The software did not get picked up by a single corporate owner or absorbed into a closed roadmap. Instead, it was shepherded for the last 30 years by an all-volunteer development crew, which Stonebraker described as “a collection of super programmers who picked up this open source project and started shepherding it forward.” The consequence for leaders is straightforward: Postgres is sovereign infrastructure. It can be used, modified, and extended without a single company controlling the keys.

To understand why that sovereignty mattered, you have to go back to what Postgres was built to do. The relational database story is often told around Ted Codd at IBM, who in 1970 pushed the idea that data should be stored in tables and accessed using a high-level query language. IBM implemented this via System R and created SQL, eventually rolling results into DB2. Stonebraker, then an assistant professor at UC Berkeley, implemented Codd’s ideas too, building a working prototype and later a full-scale implementation of Ingres. Ingres did not use SQL, it used QUEL, and a relatively primitive version was released gratis for academic research.

But by the early 1980s, Stonebraker had “pushed the code off a cliff” and started building something new: Postgres. His core goal was not just to store more kinds of data, but to make databases extensible for the real world, where applications don’t just handle integers and strings. Stonebraker explained that business pressures were pushing database systems beyond basic accounting types toward complicated CAD and GIS data. That meant the ideal database needed to support more data types, user-defined data types, user-defined operators, and user-defined functions. And that is where it gets technical in the most business-relevant way: “The devil is in the details.” You have to teach the query optimizer about new types, work out commutative rules, and optimize them.

Postgres’ most successful outcome from that design gamble was abstract data types (ADTs). Stonebraker and his team were also aiming to incorporate work from Chris Date on referential integrity, aiming for semantic consistency between foreign keys and primary keys. He wanted a rules engine that would continually monitor changes and make decisions based on those changes, and he wanted crash recovery. In the end, the crash recovery and rules engine “never quite worked out.” The ADTs did, and Stonebraker later said that his work on ADTs was probably the major reason he landed the Association for Computing Machinery’s 2014 A.M. Turing Award.

So yes, Postgres was born from serious research instincts. But it survived because the community made it practical, fast, and compatible with industry expectations. When Yu and Chen resurrected Postgres in 1995, they jettisoned the poorly-running rules engine and disaster recovery features and, most importantly, replaced QUEL with SQL, the then-industry standard. The resulting Postgre95 release, later PostgreSQL, shifted Postgres from an academic artifact into something developers could bet on.

That decision created a kind of “compatibility gravity” that now pulls entire ecosystems. Postgres’ wire interface is widely used as a base for building other database systems, including CockroachDB, YugoByteDB, and TimeScale. Major cloud providers also built their own database-as-a-service offerings on Postgres: Amazon Web Services, Microsoft Azure, and Google Cloud each have their own services that are fully Postgres compatible. Stonebraker put it bluntly: “The elephants have basically bet the ranch on Postgres.” Even AWS’ graph database service is built on Postgres, and Stonebraker quipped that the relational implementation of the graph database is “almost always faster, usually substantially faster, than doing it natively.”

This is where the executive conversation moves from history to procurement risk and product strategy. In the PGDay session, Tom Kincaid, vice president of EDB, pointed to extensibility as a major adoption lever. ADTs gave Postgres a path into geospatial markets and later document databases. Kincaid told The Register that Postgres could quickly provide developers with what they needed for storing, retrieving, and searching JSON documents, and that combining SQL with many different data types helped it thrive across application trends. He also cited code quality, saying it is held to the “highest standard of review,” plus the optimizer’s quality. Finally, permissive licensing matters at board level too. It allows startups and project leaders to build derivative products without legal fear.

Yet even the king of survival still has gaps worth watching. Postgres still does not have file-level encryption, according to PGDay discussions. Long-time contributor Bruce Momjian ran down a long list of missing features and said many are currently being grappled with by the development team. For decision-makers, this matters less as a scoreboard and more as a governance question: if commercial databases have certain compliance-native features, your architecture might inherit work. That work can land in engineering backlogs, audit processes, or the uncomfortable space between “we’re mostly compliant” and “we’re signed off.”

The meta-story here is that Postgres’ trajectory was not smooth, and it was not controlled by a single owner. It was reshaped by incentives, compatibility, and a volunteer community that kept the core architecture alive even when the original creator moved on. Today’s leaders are effectively living inside that bargain: sovereign infrastructure that cloud giants supported, and extensibility that helped it absorb new application patterns. The strategic stakes are simple. If you are choosing database platforms, you are not just buying performance. You are betting on an ecosystem that can survive abandonment, evolve with developer needs, and close feature gaps on a timeline you will feel in audits, migrations, and product releases.