Postgres-operator

What is postgres-operator image?

The postgres-operator image runs a Kubernetes Operator that automates provisioning, scaling, failover, backups, and configuration management for PostgreSQL clusters. It removes the operational overhead of managing databases manually by using Kubernetes CRDs to declaratively define cluster topology, users, storage, connection settings, and high-availability behavior. Postgres Operators typically support automated Patroni-based consensus management, rolling upgrades, connection pooling (via PgBouncer), monitoring integration, and scheduled backups to S3-compatible storage. In modern infrastructure, the postgres-operator image is widely used to provide production-grade PostgreSQL inside Kubernetes without relying on external DBaaS services, enabling teams to run resilient stateful data services alongside applications.

How to use this image

The postgres-operator image is not run directly with docker run; it is deployed into Kubernetes with Helm charts or manifest bundles and managed through Kubernetes CRDs.

Install using Helm (Zalando operator example):

helm repo add postgres-operator-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm install pg-operator postgres-operator-charts/postgres-operator \
  --namespace postgres-operator --create-namespace

Define a PostgreSQL cluster using a custom resource:

apiVersion:"acid.zalan.do/v1"
kind:postgresql
metadata:
name:my-postgres
namespace:default
spec:
teamId:"example"
volume:
size:10Gi
numberOfInstances:3
users:
appuser: []
databases:
appdb:appuser
postgresql:
version:"15"

Once applied, the operator provisions StatefulSets, persistent volumes, configuration, failover logic, and monitoring hooks. Backups and restores can also be scheduled or triggered through CRDs.

Image variants

Published under repositories such as zalando/postgres-operator and crunchydata/postgres-operator, common variants include:

Operators frequently release updates alongside PostgreSQL versions and CRD changes; production environments should always pin explicit tags and test upgrades.