Best of 2022: Why Run Postgres in Kubernetes?

As we close out 2022, we at Container Journal wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

PostgreSQL is an amazing open source project that has concretely contributed to innovation in the database management industry for at least the last two decades. Built on the solid foundations that were conceived by one of the luminaries of database science, Michael R. Stonebraker, over time PostgreSQL has become one of the most popular database management systems in the world, especially in virtualized and bare-metal installations.

Enterprise-level features have been consistently added year after year, one major release after the other, including Standard SQL, transactional DDL, continuous backup, point-in-time recovery (PITR), native streaming replication (async/sync), declarative partitioning for horizontal table partitioning, extensibility (with extensions like PostGIS for geographical databases), parallel queries for vertical scalability, JSON support for multi-model hybrid databases and so on.

Historically, running a database like PostgreSQL inside Kubernetes has been seen as an anti-pattern, as the initial evolutionary phase of the most popular container orchestration system was primarily focused on elastic scalability of stateless applications.

However, the trend has been changing since the introduction of local persistent volumes in Kubernetes 1.14 (March 2019) and the increasing adoption of the operator design pattern to help manage complex applications (like a database) by extending the Kubernetes controller with Custom Resources. Openly governed groups like the Data on Kubernetes Community (DoK) are also contributing to raise general awareness of running stateful workloads like databases in Kubernetes. 

DoK conducted a survey in September 2021 (the first of its kind) with a sample of 500 executives and technology leaders which revealed 90% of them believe that Kubernetes is ready for stateful workloads and databases, providing clear benefits for the organization in terms of standardized infrastructure management. The same survey also reports that significant challenges persist; in particular, the shortage of Kubernetes skills and inadequate quality of operators.

My company, my team, and myself, as active members of both the PostgreSQL and the Data on Kubernetes community, believe that PostgreSQL and Kubernetes complement each other, potentially bringing the best overall experience of this open source database.

PostgreSQL should indeed run inside Kubernetes; alongside applications, not outside—provided that your organization has already adopted Kubernetes and possesses both Kubernetes and PostgreSQL skills. In terms of assistance, it is fine to rely on third-party professional support for either or both of them.

After all, a database is nothing more than an application, though they are a special kind—given that data is the most important asset of an organization. This additional level of care and attention translates into a deeper understanding of Postgres architectures, CPU/memory resource usage on the worker node and storage, ensuring performance and data reliability.

What also makes a difference is a good operator. PostgreSQL is a complex application and, as such, it is an ideal use case for the operator pattern. Even though you can run PostgreSQL as a pure container in a pod and let Kubernetes handle resource management, self-healing, and data replication at the storage level, this approach doesn’t take advantage of over a decade of evolution of this open source database management system in the business continuity area.

Such an operator should be able to cover all aspects of the life cycle of a database, using declarative configuration, and relying on the primary/standby architecture that PostgreSQL supports via native streaming replication—including synchronous replication which can even be enabled/disabled at ACID transaction level.

The ideal Postgres operator should be integrated with the Kubernetes API server for immediate detection of unexpected failures through reliable liveness and readiness probes, and for the prompt reaction as part of self-healing procedures, such as: Automated failover with low recovery time objectives (RTO) for high availability and the recreation of a standby following a permanent failure of the hosting node.

This operator must leverage PostgreSQL’s native capabilities for continuous backup and point-in-time-recovery (PITR), so as to provide the best outcomes in terms of disaster recovery after unexpected hardware failures and human errors such as an “UPDATE” query without a “WHERE” condition. Recovery point objectives (RPO) near zero in the same data center, or systematically lower than five to 10 minutes across regions are certainly possible with open source stacks based on Kubernetes and PostgreSQL, managed by an operator.

Security must be pervasive, embodied in the operator and its development cycle, by taking advantage of all the available capabilities in both Kubernetes and PostgreSQL, starting from TLS connections and TLS client authentication—possibly integrated with tools that are part of the CNCF ecosystem like cert-manager. Security is also implemented through regular updates of both the operator image and the operand images containing PostgreSQL. This can happen when a new minor version of PostgreSQL is released (e.g. from 14.1 to 14.2), or when a newer container image that fixes known vulnerabilities is available. In such cases, a good PostgreSQL operator should implement rolling updates in an automated way, by first replacing the container image in each replica, one at a time, then issuing a switchover of the primary on the most aligned replica and, finally, realigning the former primary to the current one.

Each PostgreSQL cluster must be a good citizen in the Kubernetes cluster and in the overall IT infrastructure, with solid troubleshooting processes and seamless integration of monitoring, logging and audit—partially in line with the maturity level 2 for cloud-native databases described by Jeff Carpenter.

When this happens, the organization can potentially exploit the real benefits of developing, deploying and running microservice applications inside Kubernetes within a cloud-native infrastructure. And when this is associated with the presence of a Westrum generative DevOps culture, the outcomes are even more evident, as the latest DORA “State of DevOps 2021” report states. Technical capabilities like source control, trunk-based development, continuous integration, continuous testing, continuous delivery, deployment automation and shifting left on security, to name a few, enable application developers to autonomously create applications that are based on microservice architecture and that extend over the associated database(s). Such databases can be PostgreSQL, in Kubernetes, managed by the selected operator. Developers, PostgreSQL DBAs, Kubernetes administrators are some of the actors that work together in a multidisciplinary team that owns the application and the database, with the evident benefit of a reduced collective cognitive load which results in more agility.

Extending the microservices architecture to the Postgres database creates a continuous flow between the two ends of an automated pipeline: The developer’s creativity and the customer’s experience. For every commit that is pushed to the source code repository, such pipelines build immutable application containers, go through automated tests directly in Kubernetes (for example, using “kind”) that include the PostgreSQL database, verify quality and security, run integration tests directly in Kubernetes and even automatically deploy the changes in production (using canary or blue/green deployment strategies).

Thanks to Kubernetes’ pillars of infrastructure abstraction, immutable containers and declarative configuration, we ensure no variability between what runs in the developer’s laptop and what runs in staging or production environments, dramatically increasing development velocity.

PostgreSQL also makes life easier in terms of database change management through capabilities like transactional DDL, JSON data, schemas, stored functions, and optimized column additions.

There are many reasons to run PostgreSQL in Kubernetes, most of which are technical and vary depending on the persona. Application developers might be tempted by PostgreSQL’s ability to handle both relational and unstructured data in JSON using SQL, while Kubernetes administrators would lean on declarative configuration and immutability of the selected Postgres operator.

However, I’d like to pick a more challenging reason; one that probably appeals to executives and focuses on an organization’s culture; that is, focused on human beings more than technology. The opportunity to transform the organization into a better and happier one by developing disruptive applications that generate immediate value to the customer and that reliably store their data in their own PostgreSQL database inside a cloud-native infrastructure based on Kubernetes and friends.

This open source stack unleashes freedom of choice and reduces the risk of vendor lock-in at multiple levels:

  • You can run Kubernetes on-premises, in the public cloud, on hybrid cloud and multi-cloud
  • You can choose Kubernetes clusters managed by the organization or a third party (like EKS, AKS or GKE, for example)
  • You can choose to manage PostgreSQL by yourself or rely on a third-party organization that provides professional support
  • You can adopt “vanilla” Kubernetes or a third-party distribution of Kubernetes
  • You can decide to run Kubernetes on a VM-based environment or even bare metal
  • You can deploy your PostgreSQL databases in a shared architecture where multiple PostgreSQL instances run on the same Kubernetes worker node and share network disks, or in a shared-nothing architecture where a Kubernetes node is dedicated to a single PostgreSQL instance—possibly with directly attached storage.

The good thing is that this choice is now yours.


Join us for KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain (and virtual) from May 16-20—the first in-person European event in three years!