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

High availability (HA) minimizes downtime in the event of failures and is crucial for production deployments. To achieve high availability, you need to have
[ParadeDB Enterprise](/deploy/enterprise) deployed inside a [CNPG Kubernetes cluster](/deploy/self-hosted/kubernetes).

## 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.

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](https://cloudnative-pg.io/legacy/1.18/architecture/).

## Enable High Availability

Prior to starting the CNPG cluster, modify the `values.yaml` file to increase the number of instances.

```yaml ParadeDB Enterprise
type: paradedb-enterprise
mode: standalone

cluster:
  instances: 3
  storage:
    size: 256Mi
```

The number of replicas is equal to `instances - 1`. Having at least `3` instances guarantees that a standby will be available even while a failover process is occurring.

## Synchronous Replication

Between physical replicas, ParadeDB requires the use of a few settings (which are automatically set by [CNPG](/deploy/self-hosted/kubernetes)) in order to avoid query cancellation due to ongoing reorganization of the data on the primary replica.

- `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.

## Synchronous 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](https://cloudnative-pg.io/legacy/1.18/replication/#synchronous-replication) 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](https://pgbarman.org/). To configure the frequency and location of backups, please consult the [CloudNativePG Backup documentation](https://cloudnative-pg.io/legacy/1.18/backup_recovery/).