---
title: PostgreSQL High Availability
url: "/docs/databases/postgresql-high-availability/"
canonical_url: https://docs.blossom88.com/docs/databases/postgresql-high-availability/
markdown_url: https://docs.blossom88.com/docs/databases/postgresql-high-availability.md
summary: Dedicated standby, automatic failover, and planned switchover for PostgreSQL
categories:
- data
- databases
- high availability
---

# PostgreSQL High Availability

Blossom can restore PostgreSQL write availability automatically after a primary
failure. The design separates recovery from read scaling so every Database Node
has one clear role.

## Dedicated Standby

The standby is a setting on a Dedicated PostgreSQL Database, like Multi-AZ:
check **Standby with automatic failover** on the Database, or set
`standby: true` in the CLI or API. The Database then has
one dedicated standby kept separate from the primary. It continuously follows
the primary but does not accept application traffic during normal operation.

    blossom database_instance:update --id database_instance-100 --data '{"database_instance":{"standby":true}}' --follow

Reserving the standby is intentional. Application reads cannot consume the
promotion target, and failover always has one known candidate. The standby is
not a replacement for recovery backups; high availability requires configured
Backup Storage and current recovery protection.

## Read Replicas

Read replicas serve read-only application traffic. A PostgreSQL Database can
have up to 15 direct replicas, each with a stable private endpoint and per-node
monitoring.

Replicas are not automatic failover candidates. A delayed or unhealthy replica
does not block promotion of a healthy standby.

## Automatic Failover

Blossom combines PostgreSQL readiness, replication health, and independent
failure signals. These signals detect trouble quickly, but detection alone does
not authorize promotion.

Before promoting the standby, Blossom requires:

1. a healthy standby with a known replication position
2. proof that the old primary cannot accept writes

Blossom then promotes the standby and moves the Database's stable private
endpoint. Applications retain the same hostname, and no failover command is
required.

Write availability returns before slower repair work. Blossom rebuilds the
former primary as the new standby and re-seeds read replicas afterward. If it
cannot prove fencing, it leaves the Database degraded instead of risking two
writable primaries.

## Planned Switchover

Exercise the promotion path without waiting for a failure:

    blossom database_instance:switchover --id database_instance-100 --yes --follow

Planned switchover fences the current primary, catches the standby up, promotes
it, and moves the stable endpoint. The former primary becomes the new standby,
and read replicas are brought onto the promoted primary's timeline.

This is the supported way to test application reconnection and operational
expectations. A normal Database restart does not intentionally trigger
failover. Blossom allows the primary to return; automatic failover proceeds
only if it does not return and fencing is proven.

## Availability Boundary

Automatic failover applies to PostgreSQL Databases with a healthy dedicated
standby, current recovery protection, and automatic recovery enabled.

PostgreSQL replication is asynchronous. Blossom protects data confirmed on the
standby before failure; it does not claim that an unreplicated final write will
survive sudden primary loss.

- [PostgreSQL](/docs/databases/postgres/)
- [PostgreSQL Recovery Backups](/docs/backups/managed-database/)