Crunchy Data: How Cloud-Native PostgreSQL Works with Kubernetes
As organization shift toward Kubernetes-native infrastructure, managing stateful workloads like databases requires automation, resilience, and secure operations. Crunchy Data offers a robust solution to this challenge by providing a Kubernetes-native architecture for running PostgreSQL at scale, with support for high availability, backup, and observability backed in.
This post outlines how Cruncy Data’s PostgreSQL Operator (PGO) works — its overall architecture, control flow, and structure — and how its componensts collaborate to manage the full lifecycle of a PostgreSQL cluster inside Kubernetes.
Architecture Overview: The Big Picture
Crunchy Data provides the PostgreSQL Operator (PGO) — a Kubernetes Operator that manages all aspects of PosgreSQL in a cloud-native way. It handles everything from initial deployment to failover and backup policies using Kubernetes resources.
At a high level, here’s how it fits into your cluster:
┌────────────────────────────┐
│ Kubernetes Cluster │
│ │
│ ┌────────────────────┐ │
│ │ PostgreSQL Operator│◄──┐
│ └────────────────────┘ │
│ ▲ ▲ │
│ │ │ │
│ │ │ │
│ ┌───┴────┐ ┌────┴──────┐ │
│ │ CRDs │ │StatefulSet│
│ └───▲────┘ └──┬────────┘ Kubernetes-native
│ │ │ abstraction of a
│ ┌───┴────┐ ┌──┴────────┐ PostgreSQL cluster
│ │ Spec │ │ Postgres │
│ │ (YAML) │ │ Pods │ │
│ └────────┘ └───────────┘ │
└────────────────────────────┘
Core Components
PostgresCluster (CRD)
At the heart of the operator is the PostgresCluster
Custom Resource Definition (CRD). It defines the desired state of your Postgres setup — replicas, storage, backups, TLS, and more.
Example:
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
name: my-postgres
spec:
instances:
- replicas: 3
You don’t manage pods or services manually — the operator reads this sepc and handles everything.
The Operator (Contoller Loop)
The PostgreSQL Operator watches for changes to PostgresCluster
resources. Whenever you apply or update your YAML, the operator:
- Validates the configuration
- Creates or updates Kubernetes resources (Pods, Statefulsets, PVCs, Services)
- Monitors cluster health
- Hadnels failover and promotion of replicas
- Coordinates with backup tools (e.g. pgBackRest)
This reconciliation loop ensures that the live cluster matches the desired spec.
StatefulSets + PVCs
Each PostgreSQL instance is deployed as part of a Kubernetes StatefulSet. It comes with:
- A persistent volume (PVC) for data durability
- A fixed pod identity (important for replication and consistency)
- Dedicated services for each pod
Example:
postgres-0
postgres-1
postgres-2
One of them becomes the primary node (leader), and the rest are replicas (followers), ready for failover.
Patroni for HA & Failover
Crunchy Postgres uses Patroni internally to:
- Elect a leader (Primary)
- Monitor the health of each instance
- Automatically promote replicas if the primary fails
This enables high availability and zero manual intervention during outages.
pgBackRest for Backups
Backups are managed by pgBackRest, and advanced backup/restore solution tailored for PostgreSQL.
Key features:
- Full + incremental backups
- Point-in-time recovery (PITR)
- Local or remote storage (PVCs, S3, GCS, Azure Blob)
In the PostgresCluster
CRD, you define backup targets:
spec:
backups:
pgbackrest:
repos:
- name: repo1
volume:
volumeClaimSpec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 5Gi
The operator automatically schedules and maintains backups based on this config.
TLS & Security
Crunchy Postgres supports:
- TLS encryption for all database traffic
- Automated certificate management (via cert-manager)
- Password and secret management via Kubernetes Secrets
- RBAC-integrated access
These features make it suitable for production use, even in highly regulated environments.
Connection Pooling with pgBouncer
Crunchy Postgres optionally supports pgBouncer, a lightweight connection pooler for PostgreSQL. It acts as a proxy between applications and the database, efficiently managing database connections.
This is especially useful in Kubernetes environments where short-lived or bursty workloads (like microservices or health checks) can overwhelm Postgres with too many open connections.
By pooling and reusing connections, pgBouncer:
- Reduces resource load on the database
- Improves throughput and response time
- Helps scale applications more effectively
It can be deployed alongside the database with configurable pooling modes like transaction
, which is ideal for cloud-native setups.
Other Optional Components
- pgAdmin: Web UI for managing Postgres databases
- Monitoring Stack: Prometheus + Grafana dashboards
You can enable these as needed to complement your stack.
Summary
Here’s the typical control flow when deploying Cruchy Postgres:
- You define a
PostgresCluster
resource in YAML. - The operator detects it and creates:
- StatefulSets for primary + replicas
- PVCs for persistent storage
- Services for internal and external access - Patroni bootstraps the cluster and handles failover logic.
- pgBackRest schedules backups according to the spec.
- TLS certs and secrets are mounted into pods securely.
Any time you update the YAML (e.g. scale replicas, change storage), the operator reconciles the state.