ElastiCluster doesn’t invent its own consensus. Each engine fails over with the mechanism its community already
trusts, Patroni, replica-set elections, Sentinel or Galera, and ElastiCluster sets it up, keeps it configured and
gives your applications endpoints that follow the primary.
orders-db: endpoints, the etcd quorum and replication between three members.Interactive demo, simulated data.
Open this screen in the demo
What happens when a primary fails
When the primary stops answering, its lock in etcd expires and Patroni promotes the most suitable standby,
preferably a synchronous one that already has every acknowledged write. HAProxy checks each member’s role, so
the rw endpoint moves to the new primary by itself. When the old primary returns, it rejoins as a
replica.
None of this involves the ElastiCluster control plane. It plans and observes; the data plane fails over on its
own, even while the control plane is down or being upgraded.
In the demo, open Demo controls, choose Primary failure → automatic failover
and watch the alerts fire, the primary move and the old primary rejoin.
1. Normal operation
Applications write through the rw endpoint to the primary, db-1. The synchronous standby, db-2, confirms each commit.
2. The primary stops responding
db-1 goes silent. Its leader lock in etcd expires, and Patroni on the remaining members notices.
3. The standby is promoted
Patroni promotes db-2. As the synchronous standby it already holds every acknowledged write.
4. The endpoint follows
HAProxy health checks send rw to db-2 and writes resume. db-3 replicates from the new primary.
5. The old primary rejoins
When db-1 is back, it rejoins as a replica. The control plane was never needed for any of this.
An illustration of automatic failover as ElastiCluster is designed to run it for PostgreSQL (planned for v0.1).Simulate it in the demo
One proven mechanism per engine
The failover targets below are measured from detection to the first successful client write, in the worst case.
They are design targets each release has to meet in automated failure tests, not results from a release.
Engine
Failover by
Smallest highly available layout
Failover target
PostgreSQL
Patroni with an etcd quorum
3 data members, or 2 plus a witness
≤ 45 s
MongoDB
Replica-set elections
3 or more data-bearing members
≤ 30 s with drivers that retry writes
Valkey
Sentinel (three Sentinels)
Primary and replica, plus a third server or witness
≤ 20 s with at least two replicas
Dragonfly
Valkey Sentinel (beta)
Primary and replica, plus a third server
No target yet
MariaDB
Galera quorum
3 or more members
≤ 10 s to move the writer
Garage S3
Replication across nodes and zones
3 nodes for three copies
Reads and writes continue with 2 of 3
Endpoints that follow the primary
Every member runs its own HAProxy for the cluster, so a client can connect to any member, or to a virtual IP in
front of them, and reach the right database. For PostgreSQL the endpoints are:
rw on port 5000: the primary, through PgBouncer connection pooling.
ro on port 5001: replicas whose lag is under 100 MB, spread across them.
rw-direct on port 6000: the primary without the pooler, for migrations, LISTEN/NOTIFY and session
state.
The port layout matches Autobase’s, so applications that move from an Autobase cluster keep their ports. Valkey
and Dragonfly get rw and ro, MariaDB a writer and readers, Garage an S3 endpoint, and
MongoDB drivers connect to the replica set directly.
Virtual IPs and other ways to connect
An optional virtual IP, managed by keepalived, follows a healthy HAProxy rather than the database primary, so a
normal failover never moves it. On networks that don’t allow a floating IP, which includes most public clouds,
use a DNS name, your own load balancer or a client that understands replication, such as libpq with
target_session_attrs=read-write. The Connect page in the console builds the connection string for
each option and shows the certificate to verify against.
Endpoints can also run on dedicated proxy servers shared by several clusters, with one virtual IP pair in
front of them, planned for v0.7.
The Connect page builds a verified connection string for each endpoint.Interactive demo, simulated data.
Open this screen in the demo
Knowing that writes really work
Every 30 seconds a small canary write goes through the real rw endpoint, through the same DNS name
or virtual IP and TLS your applications use, preferably from another server. Read, write and quorum availability
are tracked separately, so “the database is up but nothing can write” shows up as exactly that.
Guards against split brain
A Valkey endpoint only sends writes to a node that says it is primary and that a majority of Sentinels agree on.
A crashed Valkey or Dragonfly primary never restarts as primary on its own while a healthy replica exists.
Promoting a disaster-recovery standby requires proof that the old site can no longer accept writes.
A Galera cluster recovers on its own only when every member’s position is known; otherwise it waits for a person.
A server whose data disk did not mount refuses to start its database instead of starting empty.
Witness servers
A quorum needs three votes, but not three copies of your data. A witness is a small server that only votes:
it runs etcd for PostgreSQL or a Sentinel for Valkey and holds no data. Two data servers plus a witness give a
highly available PostgreSQL cluster; with strict synchronous replication, the plan tells you that losing the
only replica stops writes until it returns.
Status
PostgreSQL high availability is the first preview, v0.1. MongoDB, Valkey and Dragonfly
follow in v0.4, MariaDB Galera in v0.5 and Garage in v0.6. The HAProxy and keepalived configuration generators are
being built and checked against the real binaries now.
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.
