Supabase Multigres is now in private alpha: organizations on a paid plan can request access to run a project on a three-node Postgres cluster instead of a single primary. The nodes sit in separate availability zones of one region, and if the primary fails, a replica is promoted within seconds.
A standard Supabase project writes to one Postgres primary, which Supabase says will stay the default, so a hardware fault or a zone outage means downtime until the database is recovered. Teams that could not accept that built their own stack of replicas, a failover manager, a pooler and runbooks, and Supabase says the hardest part is making sure no committed write is lost when a replica takes over. Multigres handles that as a consensus problem built on Postgres synchronous replication. A write is acknowledged only after enough nodes hold it to survive a failure, and the surviving nodes confirm that the replica being promoted has every committed write before it accepts new ones. During a failover the gateway can hold incoming requests until the new primary is ready, without returning connection errors to the application.
Pooling is built in. Where PgBouncer forces a choice between transaction mode and session mode up front, Multigres reads every incoming request, keeps track of the session state that request builds up, and picks the handling per query, which removes the mode setting altogether. Each database user gets a separate pool, a fair-share algorithm splits the connection budget so one busy role cannot starve the rest, and prepared statements are deduplicated so Postgres parses a statement once instead of once per client.
Multigres is open source under the Apache 2.0 license and comes from the team behind Vitess, the system YouTube created to scale MySQL. It is not a fork: data stays in standard Postgres, and applications keep one ordinary connection string. Auth, the REST Data API, Storage, Edge Functions and the client libraries all work with it. Supabase says Multigres targets full Postgres compatibility, verified against the pg_regress test suite, and adds that there are some differences to be aware of.
The alpha terms, per Supabase and its Multigres docs, are narrow:
| Term | During the alpha |
|---|---|
| Access | Paid plans only, by invitation after an early access request |
| Cost | Free for up to two projects per organization; pricing may change after the alpha |
| Uptime SLA | Not covered; Supabase is not targeting production workloads |
| Region | East US (North Virginia) only |
| Not available | Realtime, point-in-time recovery (daily backups only), sharding |
Realtime is missing because Multigres does not yet support the logical replication it depends on, and a project can use Multigres or OrioleDB but not both. Sharding and custom durability policies are listed as longer-term roadmap items. High availability is a toggle in the Dashboard's project-creation form and cannot be switched on for an existing project. Compute size, disk and replica count are fixed once the project exists, and enabling Multigres migrates the database, with currently no managed path back to a standard Postgres project.
