The Place of Postgres in History

In this video, EDB Technical Fellow Marc Linster sits down with EDB Vice President & Postgres Evangelist Bruce Momjian to talk about the place of Postgres in history. Watch the video and read Bruce's blog below for a deep dive into the history of Postgres, what informed its creation, and why it continues to be the preferred database for developers around the world. 

Postgres is a relational database system that simplifies the job of software developers who write multi-user applications. It provides a reliable data store that can be queried and modified by multiple users simultaneously with minimal overhead. Complex data analysis is supported using a simple declarative language. Like much infrastructure software, you have probably used Postgres and never knew it. Odds are high that an online or in-person purchase, bank deposit, web page access, phone call, or mobile phone interaction probably involves Postgres at some stage.

Postgres started at the University of California at Berkeley in 1986. Led by Michael Stonebraker, the project was a rewrite of his successful Ingres database, with extendibility as its focus. Few software projects are this old, and even fewer are still growing in popularity.

When Internet-based development started in 1996, the goal was to provide an open source alternative to proprietary relational databases. The idea that proprietary database vendors like IBM, Microsoft, and even Oracle would promote Postgres would have been considered ridiculous. Today, proprietary databases are in decline as Postgres continues to ascend. Years ago, proprietary operating systems followed the same pattern of decline as Linux ascended.

Postgres never had the resources of billion-dollar proprietary relational database vendors, and relatively has no resources. Therefore, you would think that Postgres couldn't possibly create software comparable or superior that of proprietary vendors. However, open source software has shown that superior software can be produced without money, as impossible as that might sound. Proprietary software development can only benefit from their employees, while open source can use the ideas of people anywhere in the world — people who are motivated by the opportunity to learn new skills, advance professionally, solve problems, give back to society, or improve the software they use everyday. This army of developers, while only loosely organized, can more efficiently harness their intellect to produce software than the inefficient process used for proprietary software. Though this might seem illogical, it is proven everyday by the quality and innovation of open source software.

What two characteristics have made Postgres so successful? They might not be obvious, but they are open source development and extendibility. Open source allows Postgres to improve and innovate faster than proprietary databases, and its extendibility allows it to handle the data used by today's workloads more seamlessly that any other relational database. Relational theory is more than 50 years old, and web browsers, mobile applications, complex document, GIS, GPS, social media, and data warehouse needs didn't exist then.

Traditional relational systems have struggled to adjust to non-relational requirements, with each new data need requiring a database redesign to enable it. Because Postgres was extendable, and already had some non-relational data types, adding new ones never required a redesign, and the new data type were added seamlessly. No other relational database can do that, and this ability has continued to attract users. People got tired of having to maintain, query, and integrate specialized data stores for each non-relational data need. Postgres has become the data store to contain them all. Postgres has even used its extendibility feature to provide artificial intelligence capabilities.

The design of Postgres has always been minimal, in the sense that it relies as much as possible on external facilities to accomplish its tasks. Connection pooling, failover, backup management, and monitoring mostly rely on external tooling. Rather than have one solution, Postgres encourages multiple external projects to coexist and meet the needs of diverse users. Postgres also relies on the operating system and its tooling as much as possible to allow it to be streamlined and have minimal external requirements. This allowed it to easily handle solid state drives when they arrived, as well as container and cloud deployments. Postgres could not have anticipated these developments, but when they arrived, it was ready since it already had minimalist design.

As I stated earlier, Postgres can't compete with the resources of proprietary vendors so it leans on its strength — the ability to harness the intelligence of a massive number of developers and users. Many are volunteers, some are employed by companies that use Postgres, and some are employed by vendors that supply Postgres software and services. Anyone can send an email and give their suggestions on how to improve the software. This interaction during the entire development process (feature desirability, design, implementation, testing, and deployment) cannot be matched by proprietary vendors. Even Postgres's teams are structured to distribute responsibility and have minimal impact on the free flow of ideas. The Postgres core team has a minimal charter, and can't have a majority employed by a single company. The software license is also minimal, allowing the use of the software for any purpose, including in proprietary products.

These distributed structures are also designed to guarantee that the project remains under the control of its user base and never under the control of a single company. Company-controlled software development has many downsides. The Postgres leadership makes decisions looking years or decades ahead since they are stewards of source code that is almost 40 years old. While Postgres has always played the long game, other database software focused on more immediate goals, and took shortcuts to achieve them. Over time, these shortcuts created technical debt that eventually slowed down Postgres's competitor, and they eventually faded. The Postgres approach was slower, but our streamlined design and long-term focus eventually achieved what no other database could.