Sitemap

Crunchy Data: How Cloud-Native PostgreSQL Works with Kubernetes

3 min readApr 7, 2025

--

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:

  1. You define a PostgresClusterresource in YAML.
  2. The operator detects it and creates:
    - StatefulSets for primary + replicas
    - PVCs for persistent storage
    - Services for internal and external access
  3. Patroni bootstraps the cluster and handles failover logic.
  4. pgBackRest schedules backups according to the spec.
  5. 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.

--

--

Jimin
Jimin

Written by Jimin

DevOps engineer and tech enthusiast. Sharing tech insights to simplify the complex. Let's connect on LinkedIn! https://www.linkedin.com/in/byun-jimin/

No responses yet