Postgres Build 2020 Session Spotlight: The Postgres Ecosystem

In this blog, we will be talking about The Postgres Ecosystem. PostgreSQL is the world’s most advanced database system, and it is produced by PostgreSQL Global Development Group (PGDG). Looking at all of the projects within PostgreSQL and their lifecycle, as well as considering the funding for these efforts is important to understand the ecosystem.

The Postgres community is generally thought of as comprising the following groups:

1. Core - small team that oversee the project
2. Committers - expert developers with commit rights to the source code
3. Contributors - other developers who submit code and/or reviews
4. Commentators - experts who contribute ideas and other aspects

Collectively, they are referred to as “Hackers.” Customers using PostgreSQL also play a role in the PostgreSQL community, which I’ve broken down into these 3 additional groups

1. Careerists - professionals who work with PostgreSQL regularly
2. Customers - people using Postgres in their stack, without necessarily being experts
3. Confused - people who don’t knowingly use Postgres yet (even though many do!)

All of the above groups make a big contribution to the PostgreSQL project and need to work together to make the most of the software. We have DBAs, SysAdmins, customers using PostgreSQL for their mission-critical applications. 

Postgres Stability

The most important feature of PostgreSQL is the stability of the database engine. PostgreSQL is developed with regular annual release cycles. The database is backward compatible, giving external contributors and customers time to plan deployment. 

Each deployment has a 5-year lifecycle, and every release has full documentation available. The project contains security and quality assurance teams that actively manages and protects the database from attacks and performance bottlenecks. 

Maintaining a single codebase with a tightly controlled “quality gate” enables continuous development with little to no roadblocks caused by technical debt.

The Agility of Postgres Ecosystem

Although the project makes regular steady progress, some additional features are required sooner by users, so there are some more agile mechanisms for those wanting to implement new features into the database server.

Forking the code to produce a new version is an easy way to produce new features, but can easily introduce bugs and requires more maintenance on the part of the developer. Early forks of PostgreSQL code led to commercial products such as Illustra, Mammoth, Neteeza or Redshift, which unfortunately haven’t maintained their compatibility with later versions and in some cases have died as a result. So forking the code is typically only used now by database researchers investigating new database technology, such as Postgres-R, pgCluster or MayBMS, though be warned these are not usable in production.

PostgreSQL vendors typically support an altered product version, allowing them to provide their extended services around their PostgreSQL version—which can be referred to as Value Added Distros (VAD) for Postgres. Examples of this would be EDB or Greenplum. In this case, the VAD stays as close as possible to the core and is updated regularly to allow the user to take advantage of new features from Postgres core and new features added to these private versions.

Developing Extensions or Plugins on top of PostgreSQL allows external projects to add new functionality using fully supported APIs and helps build a very agile product. The most notable extension of PostgreSQL is PostGIS, which is the world’s most advanced GIS system. We also have extensions that aid in maintaining high availability and backup recovery for PostgreSQL such as EDB Postgres Distributed. Overall, extensions provide the best agility, while PostgreSQL engine provides the stability customers look for.

Postgres Challenges

Customers tend to inquire about the product licensing—whether they should go for the open-source licensing or select a closed source version. The key element to focus on here is: How do we pay for features?

We all want software to be open source, but we need a model that encourages both people and companies to invest in software development. The PostgreSQL community provides both by allowing individuals to get involved directly in their future database, as well as allowing companies to release additional functionality via value-added distributions and extensions.

Customers often discuss which database system to use; normally the debate is about SQL vs. NoSQL and the performance of each database engine. Postgres provides support for SQL modeling as well as the NoSQL business requirements, yet without compromising the performance of the system and the developer experience around the product. 

PostgreSQL project has 29 active Committers currently. They are PostgreSQL developers and are working full-time with a company that generates revenue by providing PostgreSQL services to customers. More than half of these active Committers have worked at EDB. EDB, now with 2ndQuadrant, has been supporting the PostgreSQL project with funding and community across 15 years and continues to do so. 

PostgreSQL community is a global and diverse community made up of independent contributors and enterprise organizations. Industry-leading companies such as EDB provide the funding that keeps the PostgreSQL development running. The engagement and interactions between community and industry help build a stable and agile product that customers can rely upon.