Skip to main content

ADR 004: Postgres Opertor

Date: 2025-09-10

Status: Proposed

Decision Makers: @cr0ssing @DerLinne @luckey

Context​

For CIVITAS/CORE V2 we need a cloud‑native solution to provision and operate PostgreSQL in our Kubernetes environments. The choice must be open‑source, production‑grade, and support: backups & PITR, role/secret management, read replicas, multiple databases/clusters, extension management, and high availability. We evaluated operator‑based approaches and compared leading open‑source operators.

Checked Architecture Principles​

  • [none] Model-centric data flow
    • not applicable
  • [full] Distributed architecture with unified user experience
  • [full] Modular design
  • [full] Integration capability through defined interfaces
  • [full] Open source as the default
  • [full] Cloud-native architecture
  • [full] Prefer standard solutions over custom development
  • [partial] Self-contained deployment
    • depends on external object storage for backup
  • [full] Technological consistency to ensure maintainability
  • [full] Multi-tenancy
  • [full] Security by design

(if partial, then this topic should be commented)

Decision​

Adopt CloudNativePG (CNPG) operator as the standard PostgreSQL operator for CIVITAS/CORE 2.

Reasons:

Strong OSS posture and documentation; active community and clear release/process hygiene.

Feature completeness: automated backups & PITR (Barman), HA with streaming replication and automatic failover, declarative database/role/secret management, rolling minor upgrades and supported in‑place major upgrades via pg_upgrade, scalable replica management, and robust extension handling (including image volume extensions).

Operational ergonomics: clean CRDs, straightforward GitOps workflow.

Risk profile: no noteable risks.

Performance: on par with other mature operators in our tests; notably better than StackGres in our scenario.

Consequences​

Platform standardization: CNPG CRDs become the canonical interface for Postgres clusters.

Alternatives​

Zalando Postgres Operator: Feature‑complete and known from CIVITAS v1. Discarded due to weaker repo maintenance/risk signals; would remain a fallback if CNPG proves unsuitable.

Crunchy Data PGO: Solid capabilities (pgBackRest, HA, user mgmt) and comparable performance. Discarded due to more SQL‑script heavy areas in config and slightly higher operational complexity for our GitOps model.

StackGres: Not selected; web‑UI‑centric workflow, SQL‑driven config friction, and significantly worse performance in our tests.

See also​