Supabase brings automatic Postgres failover to private alpha
Multigres, built by the Vitess team, promotes a replica within seconds of a primary failing, using one unchanged connection string and no fork of Postgres.
Supabase opened private alpha access to Multigres on 29 October, its first deployment of the project since the open-source v0.1 release last year. Multigres is not a Postgres fork: your data stays in standard Postgres, while Multigres manages the cluster around it, handling routing, pooling, replication, failover and backups.
Projects run on three Postgres nodes spread across availability zones, currently limited to East US (North Virginia). Instead of treating failover as a monitoring problem, Multigres uses a consensus protocol built on Postgres synchronous replication: a write is only acknowledged once it has reached enough nodes to survive a failure, so a promotion after a primary goes down loses no committed data. Supabase says failover happens within seconds. The application keeps using one standard Postgres connection string throughout, no code changes needed.
Access is limited to organisations on a paid plan, free for up to two projects per org during the alpha, and compute size is fixed once a project is created. You request access through a form on Supabase’s site and get onboarded gradually.
Why it matters: high availability for Postgres has usually meant stitching together your own replication and failover tooling, or paying a managed provider a premium for it. If Multigres works as described, that becomes a checkbox on an existing Supabase project instead of a separate piece of infrastructure to run.
The caveat: it’s a private alpha, one region, and compute size can’t be changed after creation, so it’s not yet something to put in front of production traffic you can’t afford to lose.