---
title: High Availability
description: Use read replicas to minimize downtime in production
canonical: https://www.paradedb.com/docs/operate/deploy/self-hosted/high-availability
---

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](/operate/deploy/enterprise), which is included with [ParadeDB Cloud](/operate/deploy/cloud). To self-host it, [contact sales](mailto:sales@paradedb.com).

## 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](/operate/deploy/self-hosted/kubernetes#deploying-with-the-helm-chart) configures these settings automatically.

- `hot_standby_feedback=on` — The [`hot_standby_feedback`](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK) setting controls whether nodes acting as `hot_standby`s (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`](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-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](https://www.postgresql.org/docs/current/warm-standby.html#SYNCHRONOUS-REPLICATION) for configuration details.