Postgres Operator is an MIT-licensed Kubernetes operator, written in Go and developed at Zalando, that creates and manages highly available PostgreSQL clusters through Postgres manifests (CRDs), built for platform and infrastructure teams that want database-as-a-service inside their own Kubernetes clusters.

What it is

Postgres Operator runs inside a Kubernetes cluster and turns declarative Postgres manifests (CRDs) into running, replicated databases. It is configured only through those manifests, so no direct Kubernetes API access is needed from CI/CD pipelines, and it is powered by Patroni for streaming replication and by Spilo for the Postgres container image. The project lives in the Kubernetes operator ecosystem and promotes infrastructure as code over manual operations.

The concrete problem it solves is manual PostgreSQL provisioning and lifecycle management. Without it, a team assembles replication, failover, backups, connection pooling, and certificate handling by hand, then repeats that work for every cluster. The operator replaces that work with reconciliation of cluster manifests, covering rolling updates, volume resizing, major version upgrades, restores, and cloning. Its own topics name the role directly: database-as-a-service, managed-services, and data-infrastructure on Kubernetes.

Key capabilities

• Rolling updates on Postgres cluster changes, including quick minor version updates.
• Live volume resize without pod restarts, on AWS EBS and PVC.
• Database connection pooling with PGBouncer.
• Fast in-place major version upgrade, including a global upgrade of all clusters.
• Restore and cloning of Postgres clusters on AWS, GCS, and Azure, with optional logical backups to an S3 or GCS bucket.
• Standby clusters built from an S3 or GCS WAL archive or a remote host, and Point-In-Time-Recovery via pg_basebackup, WAL-G, or WAL-E through Spilo.
• UI to create and edit Postgres cluster manifests, plus support for custom TLS certificates. PostgreSQL 18 is supported, starting from 14+.

Who uses it and how

• Platform teams running database-as-a-service on their own Kubernetes clusters; the operator has been used in production for over five years.
• Teams that drive database changes from CI/CD with no direct Kubernetes API access, editing Postgres manifests (CRDs) instead.
• Organisations on OpenShift, which the operator is compatible with, and on multi-arch environments.
• Non-cloud deployments: the operator is configurable for non-cloud environments such as bare metal and on-premises infrastructure.

Getting started

Deployment starts with the quickstart tutorial at docs/quickstart.md, with all installation paths listed under docs/quickstart.md#deployment-options. Users on the v1.x operator must read docs/migrate.md before deploying a v2 operator.

How it compares

The facts list no paid products this project replaces and name no comparable tools, so it stands alone in this registry on that axis. The only related components named are its own dependencies: Patroni, Spilo, and PGBouncer are parts it runs, not alternatives to it.

When to use it — and when not to

A self-hoster must operate a Kubernetes cluster, the operator control loop, Patroni replication, PGBouncer pooling, and object storage for backups and WAL archives on S3, GCS, or Azure, along with the TLS certificates and credentials — a platform engineering commitment rather than a drop-in database. Teams without Kubernetes expertise, or those wanting a fully managed database with no operational surface, should pick a hosted provider instead. The project carries 546 open issues and the README excerpt available here is truncated, so adopters should treat the Read the Docs documentation as the practical reference.