Skip to main content
High availability (HA) minimizes downtime when a Postgres instance fails by automatically promoting a standby instance to take its place. High availability for ParadeDB indexes requires ParadeDB Enterprise, which is included with ParadeDB Cloud. To self-host it, contact sales.

​
How High Availability Works

In a highly available Postgres cluster, ParadeDB indexes replicate to standby instances alongside your data and remain available after failover. One instance serves as the primary, while the others serve as standbys. The primary sends write-ahead logs (WALs) to the standbys, which replay them to stay in sync. If the primary server goes down, a standby server is promoted to become the new primary server. This process is called failover.

​
Standby Configuration

ParadeDB requires the following settings on standby instances to prevent query cancellations while the primary reorganizes index data. Our Helm Chart configures these settings automatically.
  • hot_standby_feedback=on — The hot_standby_feedback setting controls whether nodes acting as hot_standbys (the replicas in physical replication) send feedback to the leader about their current transaction status. ParadeDB uses this transaction status to determine when it is safe for the primary to garbage collect its segments.
  • primary_slot_name=$something — The primary_slot_name setting declares the name of the replication slot that a replica should use when it connects to the primary. In order for hot_standby_feedback to be used and persistent, a replication slot must be used.
Without these settings, ParadeDB physical replicas will see much more frequent query cancels, and will report a message recommending that they are used.

​
Asynchronous vs. Synchronous Replication

ParadeDB follows your Postgres cluster’s replication configuration. You can use asynchronous or synchronous replication depending on your durability and latency requirements.
  • Asynchronous replication lets transactions commit without waiting for standby confirmation. This avoids replication-related commit delays, but recent commits may be lost if the primary fails before they reach the promoted standby.
  • Synchronous replication makes transactions wait for confirmation from the configured number of standbys before committing. This provides stronger durability guarantees at the cost of commit latency and can block writes if too few standbys are available.
The confirmation required from standbys depends on synchronous_commit, while synchronous_standby_names determines which standbys participate and how many must respond. See the Postgres synchronous replication documentation for configuration details.