Run PostgreSQL in Kubernetes: Solutions, Pros and Cons

This post was originally published in 2022, and we’ve updated it in 2025 for clarity and relevance.

PostgreSQL was initially released in 1996, when cloud-native was not even a term. According to DB engines, it is currently the fourth most popular relational open source database. With its popularity growing and the rising trend of Kubernetes, it is not surprising that there are multiple solutions to run PostgreSQL on K8s.

In this blog post, we are going to compare these solutions and review the pros and cons of each of them. The solutions under our microscope are:

1. Crunchy Data PostgreSQL Operator (PGO)
2. CloudNative PG from Enterprise DB
3. StackGres from OnGres
4. Zalando Postgres Operator
5. Percona Operator for PostgreSQL

The summary and comparison table can be found in our documentation.

Crunchy Data PGO

Crunchy Data is a company well-known in the PostgreSQL community. They provide a wide range of services and software solutions for PG. Their PostgreSQL Operator (PGO) is fully open source (Apache 2.0 license), but at the same time container images used by the operator are shipped under Crunchy Data Developer Program. This means that you cannot use the Operator with these images in production without the contract with Crunchy Data. Read more in the Terms of Use.

Deployment

According to the documentation, the latest version of the operator is 5.2.0, but the latest tag in Github is 4.7.7. I was not able to find which version is ready for production, but I will use a quickstart installation from the GitHub page, which installs 5.2.0. The quick start is not that quick. First, you need to fork the repository with examples: link.

Executing these commands failed for me:

I just ended up cloning the repo with 

Ran kustomize script which failed as well:

The instructions on the documentation page have other commands, so I used them instead. As a person who loves open source, I sent a PR to fix the doc on Github. 

Now Operator is installed. Install the cluster:

Features

PGO operator is used in production by various companies, comes with management capabilities, and allows users to fine-tune PostgreSQL clusters.

No need to go through the regular day-two operations, like backups and scaling. The following features are quite interesting:

• Extension Management. PostgreSQL extensions expand the capabilities of the database. With PGO, you can easily add extensions for your cluster and configure them during bootstrap. I like the simplicity of this approach.
• User / database management. Create users and databases during cluster initialization. This is very handy for CICD pipelines and various automations.
• Backup with annotations. Usually, Operators come with a separate Custom Resource Definition for backups and restores. In the case of PGO, backups, and restores are managed through annotations. This is an antipattern but still follows the declarative form.

CloudNative PG

This operator was maturing in EnterpriseDB (EDB) to be finally open-sourced recently. It is Apache-licensed and fully open source, and there is an EDB Postgres operator, which is a fork based on CloudNative PG. The Enterprise version has some additional features, for example, support for Red Hat OpenShift.

Deployment

Using quickstart, here is how to install the Operator:

It automatically creates cnpg-system namespace and deploys necessary CRDs, service accounts, and more.

Once done, you can deploy the PostgreSQL cluster. There are multiple exampolary YAMLs.

There is also a helm chart available that can simplify the installation even more.

Features

CloudNative PG comes with a wide range of regular operational capabilities: backups, scaling, and upgrades. The architecture of the Operator is quite interesting:

• No StatefulSets. Normally, you would see StatefulSets used for stateful workloads in Kubernetes. Here PostgreSQL cluster is deployed with standalone Pods which are fully controlled by the Operator.
• No Patroni. Patroni is a de-facto standard in the PostgreSQL community to build highly available clusters. Instead, they use Postgres instance manager.
• Barman for backups. Not a usual choice as well, but can be explained by the fact that pgBarman, a backup tool for PostgreSQL, was developed by the 2nd Quadrant team which was acquired by EDB.

Apart from architecture decisions, there are some things that I found quite refreshing:

• Documentation. As a product manager, I’m honestly fascinated by their documentation. It is very detailed, goes deep into details, and is full of various examples covering a wide variety of use cases. 
• The custom resource which is used to create the cluster is called “Cluster”. It is a bit weird, but running something like kubectl get cluster is kinda cool.
• You can bootstrap the new cluster, from an existing backup object and use streaming replication from the existing PostgreSQL cluster, even from outside Kubernetes. Useful for CICD and migrations.

StackGres

OnGres is a company providing its support, professional, and managed services for PostgreSQL. The operator – StackGres – is licensed under AGPL v3.

Deployment

Installation is super simple and described on the website. It boils down to a single command:

This will deploy the web user interface and the operator. StackGres supports both UI and regular YAML manifest deployment. UI is fully-featured and allows you to do everything that the operator supports from the CRD. Get the login and password:

Connect to the UI. You can either expose the UI through a LoadBalancer or with Kubernetes port forwarding:

Deployment of the cluster in the UI is quite straightforward and I will not cover it here.

Features

UI allows users to scale, backup, restore, clone, and perform various other tasks with the clusters. I found it a bit hard to debug issues. It is recommended to set up a log server and debug issues on it, but I have not tried it. But the UI itself is mature, flexible, and just nice!

Interesting ones:

• Experimental Babelfish support that enables the migration from MSSQL to save on license costs.
• Extension management system, where users can choose the extension and its version to expand PG cluster capabilities.

• To perform upgrades, Vacuum, and other database activities, the Operator provides Database Operation capability. It also has built-in benchmarking, which is cool!

Zalando Postgres Operator

Zalando is an online retailer of shoes, fashion, and beauty. It is the only company in this blog post that is not database-focused. They open-sourced the Operator that they use internally to run and manage PostgreSQL databases and it is quite widely adopted. It is worth mentioning that the Zalando team developed and open-sourced Patroni, which is widely adopted and used.

Deployment

You can deploy Zalando Operator through a helm chart or with kubectl. Same as with StackGres, this Operator has a built-in web UI.

Helm chart installation is the quickest and easiest way to get everything up and running:

Expose the UI:

Connect to the UI and create the cluster. 

Features

This is one of the oldest PostgreSQL Operators, over time its functionality was expanding. It supports backups and restores, major version upgrades, and much more. Also, it has a web-based user interface to ease onboarding.

• The operator heavily relies on Spilo – docker image that provides PostgreSQL and Patroni bundled together. It was developed in Zalando as well. This is a centerpiece to build HA architecture.
• As Zalando is using AWS for its infrastructure, the operator is heavily tested and can be integrated with AWS. You can see it in some features – like live volume resize for AWS EBS or gp2 to gp3 migration.

Percona Operator for PostgreSQL

Percona is committed to providing software and services for databases anywhere. Kubernetes is a de-facto standard for cloud-native workloads that helps with this commitment.

What are the most important things about our Operator:

• Fully open source
• Supported by the community and Percona team. If you have a contract with Percona, you are fully covered with our exceptional services.
• It is based on the Crunchy Data PGO v 4.7 with enhancements for monitoring, upgradability, and flexibility

Deployment

We have quick-start installation guides through helm and regular YAML manifests. The installation through helm is as follows:

Install the Operator:

Deploy PostgreSQL cluster:

Features

Most of the features are inherited from Crunchy Data – backups, scaling, multi-cluster replication, and many more. 

• • Open Source. Compared to Crunchy Data PGO, we do not impose any limitations on container images, so it is fully open source and can be used without any restrictions in production. 
  • Percona Monitoring and Management (PMM) is an open source database monitoring, observability, and management tool. Percona Operators come with an integration with PMM, so that users get full visibility into the health of their databases. 
  • Automated Smart Upgrades. Our Operator not only allows users to upgrade the database but also does it automatically and in a safe, zero-downtime way.
  • One-stop shop. Today’s enterprise environment is multi-database by default. Percona can help companies run PostgreSQL, MySQL, and MongoDB databases workloads over Kubernetes in a comprehensive manner.

 

Conclusion

Running PostgreSQL on Kubernetes opens up real opportunities, but the operator you choose will decide how smooth—or how painful—the experience becomes. If you’re ready to simplify deployments, strengthen reliability, and avoid vendor lock-in, there’s a smarter way forward. Explore how you can run PostgreSQL in Kubernetes with confidence and without compromise.