CloudNativePG is the Kubernetes operator that covers the full lifecycle of a highly available PostgreSQL database cluster with a primary/standby architecture, using native streaming replication.
It automates the steps that a human operator would do to deploy and to manage a Postgres database inside Kubernetes, including automated failover.
It doesn’t rely on statefulsets and uses its own way to manage persistent volume claims where the
PGDATA is stored.
It’s entirely declarative, and directly integrates with the Kubernetes API server to update the state of the cluster — for this reason, it does not require an external failover management tool.
Built on proven DevOps concepts like immutable infrastructure, declarative configuration, and microservice architecture, CloudNativePG exclusively relies on the Kubernetes API server to maintain the state of a PostgreSQL cluster. Additionally, CloudNativePG provides cloud native capabilities like self-healing, high availability, rolling updates, scale up/down of read-only replicas, affinity/anti-affinity/tolerations for scheduling, resource management, and so on.
CloudNativePG supports security contexts by default and implements in-transit encrypted TLS connections. If you are not happy with auto-generated certificates, you can bring your own and even integrate with cert-manager. TLS client authentication for PostgreSQL is also supported, and auditing with PGAudit can be easily enabled in a declarative way.
PostgreSQL has a reliable foundation for high availability that is built on physical replication. CloudNativePG leverages streaming replication and a file-based one as a fallback method. You can tune synchronous replication to obtain zero data loss replicas.
Define your disaster recovery objectives through continuous backup on object stores, and exploits the native Point-In-Time-Recovery capabilities of PostgreSQL by boostrapping a new cluster starting from a backup to a given timestamp.
CloudNativePG has a built-in exporter for Prometheus that can be configured and customized through user defined metrics written in SQL. Logs, including database and audit, are transparently sent to stdout in JSON format for native integration with infrastructure log management pipelines.
You can extend the primary/standby architecture by adding a PgBouncer connection pooler between your application and your PostgreSQL database. Additionally, you can take advantage of replica clusters by creating one or more disaster recovery clusters in different regions, solely relying on file based WAL shipping from an object store or using a streaming replication connection.
Most Postgres related operations can be done in a declarative way, including
management of superuser credentials, application user, and application
database. Declarative configuration also covers Postgres configuration and some
common extensions like