Supabase Puts Multi-Node Postgres in Private Alpha, Not for Production

Supabase started a private alpha of Multigres on Oct. 1, a version of Postgres that runs as a small cluster and promotes a new node within seconds when one fails. Access is by invitation, and Supabase says it is not for production (Supabase changelog, Oct. 1, 2026).

Multigres is an open-source project from the team behind Vitess, the MySQL scaling system. It sits on top of standard Postgres rather than forking it. Supabase’s changelog lists automatic failover, a single connection string, consensus-based durability and a pooler that picks statement, session or transaction mode per query. It says writes are acknowledged “only once the cluster agrees they’re durable via quorum-based consensus.”

Auth, the REST API, Edge Functions, Storage and the client libraries work against a Multigres project without code changes, according to the changelog.

Who can get in

The changelog says access is limited to invited organizations on paid plans, rolled out gradually and visible in the dashboard’s project-creation flow. It says the alpha carries no SLA and no guarantees on data or availability.

Supabase’s documentation page adds a number the changelog leaves out: up to two projects per organization can use Multigres for free during the alpha.

What you give up

The restrictions are heavy. Several are permanent for a given project:

• Point-in-time recovery is off. Only standard daily backups run.
• Logical replication is unsupported. Realtime doesn’t work.
• Multigres can only be enabled at project creation. It can’t be turned off.
• Compute, disk and replica count can’t be resized afterward.
• It runs across availability zones in one region, with no cross-region replicas.
• The docs say it is incompatible with OrioleDB and that there is “no managed path to move it back to a standard Postgres project.”

The take

This is Supabase’s answer to what happens when the primary dies. A consensus-backed cluster behind one connection string is the architecture teams get from Aurora or CockroachDB. Supabase wants to offer it without leaving Postgres.

The alpha is too restrictive to judge that claim. A database you can’t back up to a point in time, can’t resize and can’t leave is a test bed. The Vitess team has run this pattern at scale for MySQL. Failover times and the first production pilots will show whether it carries over to Postgres.

Supabase also moved OrioleDB into public beta on Oct. 1, with the same no-production warning. It is testing two deep changes to Postgres at once, and neither is ready for production.