The world in which PostgreSQL operates today is very different from its origins in 1986. Where once PostgreSQL might have been considered an academic exercise even following its initial Open Source release, today it operates in a much more dynamic environment.
Open source and traditional commercial software now work alongside one another in many data centers. Indeed, they are often competing to perform essential tasks in enterprise IT infrastructures.
In the last 31 years Postgres has matured significantly in the range of functionality it offers and the mission-critical workloads it supports. The rate of maturation has accelerated dramatically in the last five years and this year’s release, PostgreSQL 10, is no exception. Companies are demanding data management systems that can deal with complex digital applications and analytic architectures, and Postgres 10 responded to offer CIOs the feature enhancements necessary to build and deploy modern applications in agile frameworks.
However, it is not just the sheer range and quality of the technical improvements that are important with the release of PostgreSQL 10. Pivotal to the development of the release was how the PostgreSQL community invested time and planning to build out working processes and project standards. Having these in place is just as important for the long-term future of Postgres as the technology contributions of the community.
As a core member of the PostgreSQL Global Development Group and an employee of a software vendor, I have a dual perspective on the need for clear standards and processes. It is crucial the Postgres project retains the diversity of its contributions to remain independent of undue influence from one vendor or a group. We see time and again the damage caused when one vendor dominates an open source project and how it limits the potential of otherwise great software. To help enshrine independence in the Postgres community we have recognised the value of processes and standards to sustain the vigour and viability of the project. That is why it is particularly pleasing to see the development of the project’s Code of Conduct and how it is helping to set expectations around the delivery of everything from community events to the way code contributions are discussed and evaluated. Further, events and NPO guidelines help community members recognise which conferences and non-profits offer the level of openness that the community expects.
As an employee of EnterpriseDB, I see first-hand the value that professionalism and commitment to standards brings to building software, especially when deploying open source in mission-critical environments. I applaud how the Postgres community has begun to adhere to greater standards, because it strengthens the credibility of Postgres in the eyes of enterprise users. If they are to adopt Postgres for critical applications they need these assurances. Our belief and ambition at EDB is to see Postgres scale to the same heights as Linux, so the more rigorous the approach of the community the more we will see its adoption in the enterprise.
Importance of Independence and Diversity
Closely aligned to the growing professionalism of the Postgres community is the diversity and independence of the contributions. They have come from individual contributors and from companies, but importantly (as I touched on earlier) no one company controls the release cycle. EnterpriseDB is a committed contributor to the community, with many employees working on code that is added to the source tree. We are currently working on everything from pgAdmin to Hash Indexes and Query Parallelism. We make these contributions, because while EDB is providing commercially supported proprietary options based on Postgres, we fundamentally understand that contributing to the community project benefits everyone, including us. Above all, though, we are very happy being a major contributor who is not in charge of the community. EDB works alongside some of our competitors, customers and partners to improve the source code and add new functionality, but we do not control the direction of the open source project. We believe this is important, because it sustains Postgres and enables multiple contributors to help build out functionality for the diverse needs of users.
Postgres 10 is no different. We have worked on areas such as improved query parallelism, which has helped to produce a 2 to 4 times performance increase for some workloads. This is very important in today’s digital world as companies need to do complex analytics, scanning multiple tables utilising multiple processors. This alleviates workloads and improves performance. Enhancements to partitioning mean it is possible to do list or range partitioning using declarative syntax, and INSERT performance has been improved. There are also benefits for developers, because partition controls are now part of the database schema, meaning they no longer must be written into the application.
That said there are many improvements that have come from elsewhere in the community. Together they add up to enhancements that offer better management and performance as well as improved reliability, scalability and flexibility:
- Logical replication features have given DBAs the ability to control replication by table or by database, as well enabling them to easily create standbys for near-zero-downtime upgrades;
- SCRAM Authentication institutes enhanced security, which improves authentication, as neither the information stored on the server nor what is exchanged during the authentication is sufficient for unauthorised access. It can allow for restricted roles for monitoring, without needing super users;
- Quorum Commit provides DBAs with greater flexibility and performance when they require multiple synchronous replication standbys. It also allows for customisation as DBAs can specify different wait policies when designating standby servers to accept data for replication; and
- Multi-column Statistics mean that query performance improvements can be seen where data is correlated over more than one column.
It is difficult to point to one theme from a technical perspective when considering PostgreSQL 10, but it confirms Postgres is heading unquestionably towards very large-scale deployments across multiple servers with different data types on different servers. All the great work the community is undertaking to enhance functionality means that Postgres is confirming its place in the enterprise as the technology capable of supporting the vast majority of data management requirements for large corporations. But equally vital is that the PostgreSQL community is thriving, robust and independent. The community is built on a solid, professional foundation that demands rigour and responsibility from those contributing to the code. This combination of process, people and technology ensures Postgres will occupy a critical junction at the heart of enterprise IT infrastructures.
Dave Page is Vice President and Chief Architect, Tools & Installers, at EnterpriseDB.
Dave has been actively involved in the PostgreSQL Project since 1998, as the lead developer of pgAdmin, maintainer of the PostgreSQL installers and one of the projects resident Windows hackers. He also serves on the project's web and sysadmin teams and is a member of the PostgreSQL Core Team. Dave is employed by EnterpriseDB where he works as a software architect and developer on EnterpriseDB products in addition to his community PostgreSQL work.