High Availability

High availability (HA) minimizes downtime in the event of failures and is crucial for production deployments. The enterprise version of ParadeDB’s Kubernetes deployment supports high availability and is transparently managed by CloudNativePG.

​

How High Availability Works

In a highly available configuration, ParadeDB deploys as a cluster of Postgres instances. One instance is designated as the primary while the other instances are designated as standby instances. The primary server sends write-ahead logs (WAL) to the standby servers, which replicate the primary by replaying these logs. CloudNativePG calls this physical replication based on WAL shipping.

If the primary server goes down, a standby server is promoted to become the new primary server. This process is called failover.

For a thorough architecture overview, please consult the CloudNativePG Architecture documentation.

​

Configuration Options

​

Replication

By default, ParadeDB ships with asynchronuous replication, meaning transactions on the primary do not wait for confirmation from the standby instances before committing.

Quorum-based synchronous replication ensures that a transaction is successfully written to standbys before it completes. Please consult the CloudNativePG Replication documentation for details.

​

Backup and Disaster Recovery

ParadeDB supports backups to cloud object stores (e.g. S3, GCS, etc.) and point-in-time-recovery via Barman. To configure the frequency and location of backups, please consult the CloudNativePG Backup documentation.

​

Physical vs. Logical Replication

ParadeDB uses logical replication to replicate from an existing primary Postgres like AWS RDS. Logical replication is available in the open source, community version of ParadeDB.

Physical replication, on the other hand, is used for high availability within a ParadeDB cluster and is available to ParadeDB enterprise customers.