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
• PostgreSQL Recovery Backups