Cloud Parts

PGO (Crunchy Postgres for Kubernetes)

Crunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative PostgresCluster resource on top.

What it is
Relational databases,Container orchestration
Type
Open source
Made by
Crunchy Data (joining Snowflake, announced June 2025)
License
Apache 2.0 for the operator code. Crunchy’s prebuilt images are under the Crunchy Data Developer Program terms: free for development, but free in production only for individuals and organisations with fewer than 50 employees
Facts checked
6 October 2026
Website Source code

What it is

PGO adds a PostgresCluster resource to Kubernetes. The operator itself is one Deployment with one container; from your spec it creates each Postgres instance as its own StatefulSet, plus Services (hippo-primary, hippo-replicas), Secrets with connection details, an optional PgBouncer Deployment, and a pgBackRest repository host. Failover isn’t the operator’s job. Patroni runs in every Postgres pod and keeps the primary’s ID in annotations on a Kubernetes Endpoints object that acts as a lease: the primary must keep renewing it, and if it misses the deadline the replicas compare WAL positions and the most up-to-date one takes the lease. So clusters keep running even if PGO is down. Backups use pgBackRest: full, differential and incremental backups, delta restores, and up to four repositories at once on a Kubernetes volume, Amazon S3 (or S3-compatible storage such as MinIO), Google Cloud Storage or Azure Blob Storage. Schedules become Kubernetes CronJobs.

Crunchy Postgres for Kubernetes is the product built around it: PGO plus Crunchy’s images of PostgreSQL 14 to 18 with Patroni, pgBackRest, PgBouncer and extensions such as PostGIS, pgAudit, pg_cron, pgvector and the Apache-licensed TimescaleDB, and a monitoring stack built on pgMonitor, Prometheus and Grafana. The licences differ. The operator code is Apache 2.0, but the default install pulls images from Crunchy’s Developer Portal, and those images may be used in production for free only by individuals and organisations with fewer than 50 employees; bigger organisations may use them only for development, and nobody may redistribute them or use them to serve third parties. The alternatives are a Crunchy subscription or your own images, which PGO 6.0 documents building from community PGDG packages. Snowflake announced it would acquire Crunchy Data on June 2, 2025, to build Snowflake Postgres. Neither announcement says anything specific about PGO; Crunchy has kept shipping it, with 6.0 in December 2025 and patch releases through 2026.

Why teams pick it

  • A long track record: the repository dates from 2017, Crunchy calls it one of the first Kubernetes operators, and Percona built its own Postgres operator on PGO’s code
  • pgBackRest backups suited to very large databases: incremental and differential backups, delta restores, and up to four repositories mixing local volumes and clouds
  • Failover by Patroni with Kubernetes as its store, so the operator is not a single point of failure and no separate etcd is needed
  • A curated distribution: tested images with common extensions, TLS everywhere by default, PgBouncer, standby clusters across Kubernetes clusters, and Kustomize, Helm and OLM installers

Watch out for

  • The free images aren’t free for production at organisations with 50 or more employees: they need a Crunchy subscription or must build and patch their own images
  • One company steers it, and that company is joining Snowflake, whose announced plans centre on its own managed Snowflake Postgres
  • More moving parts than CloudNativePG: Patroni, a pgBackRest repository host and a StatefulSet per instance; PGO 6.0 also introduced a v1 API that existing v1beta1 users migrate to
  • The Developer Program updates only the latest two major versions of Crunchy Postgres for Kubernetes and of PostgreSQL

Alternatives

What all relational databases have in common →
Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

What PGO (Crunchy Postgres for Kubernetes) uses

Three instances, PgBouncer, and pgBackRest backups to S3 on a weekly full, daily differential schedule · yaml

apiVersion: postgres-operator.crunchydata.com/v1
kind: PostgresCluster
metadata:
  name: hippo
spec:
  postgresVersion: 18
  instances:
    - name: instance1
      replicas: 3                # Patroni picks one primary
      dataVolumeClaimSpec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 50Gi
  proxy:
    pgBouncer: {}                # creates a hippo-pgbouncer Service
  backups:
    pgbackrest:
      configuration:
      - secret:
          name: pgo-s3-creds
      global:
        repo1-path: /pgbackrest/postgres-operator/hippo/repo1
        repo1-retention-full: "14"
        repo1-retention-full-type: time   # keep full backups for 14 days
      repos:
      - name: repo1
        s3:
          bucket: acme-pg-backups
          endpoint: s3.eu-central-1.amazonaws.com
          region: eu-central-1
        schedules:
          full: "0 1 * * 0"           # Sundays at 01:00
          differential: "0 1 * * 1-6" # other days at 01:00

See it in a real stack

No architecture uses PGO (Crunchy Postgres for Kubernetes) yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2012–2026

Crunchy Data grew out of a 2012 bet that companies would choose PostgreSQL as their main relational database. In its own words, what began as the simple idea of running Postgres in a container became one of the first stateful Kubernetes operators; the operator’s repository went public in February 2017. Early versions were imperative: you drove them with a pgo command-line tool modelled on kubectl, with commands such as pgo create cluster hippo and pgo backup hippo.

By 2021 teams wanted to keep their databases in Git like everything else. PGO 5.0, released in July 2021, was redesigned around a single declarative PostgresCluster resource and Kubernetes server-side apply, tested with Argo CD, and made self-healing: delete the PgBouncer Deployment by mistake and the operator recreates it. It kept the earlier architecture in which Patroni inside each cluster handles failover and pgBackRest handles backups, so a cluster survives the operator being down. Percona’s Operator for PostgreSQL is based on this code.

On June 2, 2025, Snowflake announced it would acquire Crunchy Data to bring a managed Snowflake Postgres to its platform. Crunchy said its team would keep providing the Postgres technology its customers rely on. PGO 6.0 followed in December 2025 with a v1 API, volumes that grow automatically, and documented steps to build your own images from community packages.

Why it’s built this way

Let Patroni, not the operator, decide failover
If HA lives inside each Postgres cluster, the operator only maintains the desired definition and is not a single point of failure; Patroni stores its leader lease in the Kubernetes API, so no extra etcd is needed.
pgBackRest for backups
Crunchy’s customers ran terabyte-size databases; pgBackRest offers incremental and differential backups, delta restores that rebuild a failed node without a full copy, and several repositories at once.
From a CLI to a declarative resource
The pgo tool suited people at a terminal but not GitOps. Version 5 describes the whole cluster in one resource that the operator keeps reconciled.
Ship a certified distribution of images
Crunchy builds every component from upstream source and tests it together, and the terms on those images, not the Apache-licensed operator, are where its commercial model sits.

Timeline

  1. 2012

    Crunchy Data starts as a PostgreSQL company

  2. 2017

    Postgres Operator repository published on GitHub in February

  3. 2021

    PGO 5.0 in July: a fully declarative PostgresCluster API

  4. 2025

    Snowflake announces it will acquire Crunchy Data (June 2); PGO 6.0 in December adds the v1 API

  5. 2026

    6.0.x patch releases continue with PostgreSQL 18 and Patroni 4.1

Sources17 · facts checked 6 October 2026

Improve this page on GitHub