Three servers, a Patroni cluster with an etcd quorum, PgBouncer pooling, HAProxy endpoints that follow the primary,
and pgBackRest backups with point-in-time recovery: the setup many teams build by hand, created and operated for
you, without Kubernetes.
Single: one member, using the same Patroni and etcd tooling as a highly available cluster, so
it grows into one without a migration.
High availability: three to nine data members; etcd runs on three of them, or five from five members up.
Two members and a witness: the witness is a small server that runs only etcd, providing the
third vote without a third copy of the data.
PostgreSQL 18 is the default, with 17, 16 and 15 supported. PostgreSQL 19 arrives as a preview first and
becomes supported once Patroni supports it and the test matrix passes. One image carries PostgreSQL, Patroni, pgBackRest, PgBouncer and a curated set of
extensions, including pgvector, pg_cron, pg_partman, pgaudit, pg_repack and TimescaleDB’s Apache-licensed
edition, with separate images for PostGIS and for search and analytics extensions. You can also build your own
image on top of it.
Durability, said plainly
Choose how much a failover may lose, and the plan states the consequence:
Asynchronous: fastest; Patroni won’t promote a replica last seen more than 1 MB behind (the default), which limits how much a failover can lose but doesn’t guarantee a ceiling.
Synchronous: nothing acknowledged is lost while a synchronous standby is attached; if none is,
the cluster keeps accepting writes and raises an alert.
Strict synchronous: writes wait until a synchronous standby confirms them, and stop while none
is available. The design target is zero lost acknowledged writes across 50 failure-test runs, including all
standbys down.
Overrides that would quietly weaken durability, such as lowering synchronous_commit for a role, are
rejected or raise an alert. Data checksums are on, and fsync cannot be turned off.
Failover
With the default Patroni timers, a failed primary is replaced and the first write through rw
succeeds in roughly 27 to 40 seconds; a faster preset brings that to about 15 to 25 seconds, at the cost of
reacting to short network blips. The worst-case design target is 45 seconds. If etcd itself becomes unavailable,
failsafe mode keeps the current primary running instead of demoting it, as long as it can still reach the other
members.
Endpoints
HAProxy runs on every member and checks each one’s role through Patroni’s REST API over TLS, so a client can
connect to any member, or to the virtual IP, and land on the right server. The port layout matches Autobase.
Endpoint
Port
Goes to
rw
5000
Primary, pooled by PgBouncer
ro
5001
Replicas with less than 100 MB of lag, pooled
rw-direct
6000
Primary without the pooler: migrations, LISTEN/NOTIFY, session state
ro-sync, ro-async
5002, 5003
Synchronous or asynchronous replicas only (v0.7)
PgBouncer runs in transaction mode with pools per database and per user, and superusers can never log in through
it. TLS is required by default; a custom certificate is presented on the pooled endpoints, while direct endpoints
keep the cluster’s own authority. Without a virtual IP, use a DNS name, a load balancer or libpq’s
target_session_attrs=read-write with all members listed.
Backups and recovery
pgBackRest takes a full backup weekly and incrementals daily, with continuous WAL archiving and an extra
incremental whenever replaying the log would take longer than 30 minutes. Recover to a time, a log position, a
transaction, a named restore point or the restore point created automatically before risky operations, into a new
cluster by default. Weekly restore drills in production run pg_amcheck on a sample and your own SQL
checks. WAL-G is planned as an alternative in v0.7.
Switchover with pre-checks and the etcd leader moved first; forced failover with typed confirmation.
Rolling restarts and minor upgrades, replicas first, with a single switchover.
Adding, removing, re-initialising and replacing members; stopping and starting the whole cluster.
Configuration through Patroni, with per-member overrides, custom pg_hba rules and validated timers.
Databases and users with owner, read-write and read-only presets, and password rotation without downtime.
Recovery when etcd loses its quorum, and changing a server’s address with a plan.
Major upgrades with a rehearsal on a fork and a named commit boundary (v0.7).
Disaster-recovery standby clusters, delayed replicas and dedicated proxy servers (v0.7).
Adopting existing PostgreSQL clusters, including Autobase ones, by replication (v0.7).
Tools for the data
A SQL editor that runs read-only on a replica by default, a schema browser, sessions and locks with a blocking
tree, and query insights from pg_stat_statements arrive in v0.3; maintenance jobs such as
REINDEX CONCURRENTLY and pg_repack, and the advisor, in v0.7. Built-in alert rules cover
a missing primary, replication lag, failing WAL archiving, transaction ID age, invalidated replication slots and
waiting pooler clients.
For Patroni users
If you run Patroni today, the building blocks are familiar: ElastiCluster creates clusters with Patroni, etcd,
PgBouncer and HAProxy, and patronictl keeps working. It manages clusters it created, or that were
adopted into it by replication; it does not take over a running Patroni cluster in place.
Not included
Sharding with Citus and synchronous replication across regions are outside v1.0. Citus is possible through a
custom image.
Status
PostgreSQL is the first engine: highly available clusters arrive with the v0.1 preview,
backups in v0.2, and the DBA tools in v0.3. The PostgreSQL image itself already exists in development builds. Production
clusters cannot be created until backups are available.
The interactive demo runs the whole console on simulated data. Trigger a failover, approve an AI assistant’s
plan, restore a backup to a point in time. Nothing to install.
