The Place of Postgres in History

Explore Postgres' historical significance and enduring influence with expert insights

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. 

PostgreSQL History: A Primer

Postgres is a powerful relational database management system that streamlines the work for software developers creating multi-user applications. It offers a reliable data store that can be queried and modified by multiple users simultaneously, with minimal overhead. Through a simple declarative language, Postgres supports complex data analysis. As common infrastructure software, many people use Postgres without realizing it. Whether you're making a purchase, depositing at a bank, accessing a web page, making a phone call, or using a mobile app, you're likely interacting with Postgres at some point.

PostgreSQL originated at the University of California at Berkeley in 1986, led by Michael Stonebraker. It was a rewrite of his successful Ingres database project, focusing on extensibility. It's rare for software projects of this age to continue growing in popularity, yet PostgreSQL defies the odds.

When Internet-based development kicked off in 1996, the goal was to provide an open source software alternative to proprietary relational databases. The thought of proprietary database vendors like IBM, Microsoft, and Oracle endorsing PostgreSQL would have seemed absurd. Nowadays, proprietary databases are on the decline, while Postgres continues to gain traction, much like the rise of Linux over proprietary operating systems.

Postgres never had the resources of billion-dollar proprietary relational database vendors and has no resources. Therefore, Postgres couldn't possibly create software that is comparable or superior to 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 their employees. At the same time, open source can use people's ideas anywhere in the world – people are motivated by the opportunity to learn new skills, advance professionally, solve problems, give back to society, or improve the software they use every day. While only loosely organized, this army of developers 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 every day 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. Its extendibility will enable it to handle the data used by today's workloads more seamlessly than any other relational database. Relational theory is more than 50 years old, and web browsers, mobile applications, complex documents, 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 latest data types 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 that contains 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 depends 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 efficiently handle solid state drives and container and cloud deployments when they arrived. Postgres could not have anticipated these developments, but when they arrived, it was ready since it already had a 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 many developers and users. Many are volunteers, some are employed by companies that use Postgres, and some by vendors that supply Postgres software and services. Anyone can send an email and give suggestions on improving 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 competitors, and they eventually faded. The Postgres approach was slower, but our streamlined design and long-term focus eventually achieved what no other database could.