What's new#
Multigres is an open source operating system for Postgres, built by the team behind Vitess. It adds scalable connection pooling and automated multi-node failover to Postgres, so reads and writes continue if a node fails. With Multigres, there's no separate pooler to run, and your app can connect far more clients than one Postgres instance can hold.
Enabling Multigres transforms Postgres into a multi-node cluster instead of a single instance:
- Automatic failover — if a Postgres node fails, another node in the cluster is promoted within seconds, with no intervention required.
- No connection changes — Multigres has a single, standard Postgres connection string.
- Consensus-backed durability — writes are acknowledged only after the cluster agrees they are durable, so acknowledged commits survive failovers and split-brain scenarios.
- Built-in pooling, no mode to choose — Multigres includes a connection pooler, and unlike PgBouncer, it detects what connection mode each query needs: statement, session, or transaction mode. The pooler recycles connections aggressively whenever it's safe, holding them only when it isn't. Read how it works in Pooling without choosing a mode.
- Supabase supported features — Multigres includes support for Supabase Auth, Data REST API, Edge Functions, Storage, and all client libraries.
Availability during the private alpha:
- Available to selected organizations on paid plans. Access is being extended gradually, so the option won't appear for most organizations yet.
- Not covered by the uptime SLA, and not targeted at production workloads during Private Alpha.
Multigres targets full compatibility with standard Postgres, verified against the pg_regress test suite.
How to use it#
- Open Create a new project in the Supabase Dashboard.
- Under High availability, toggle on Enable high availability. This option only appears for organizations invited to the private alpha.
- Complete the remaining fields: database password, region, and compute size — and click Create new project.
Enabling Multigres is a choice made at project creation and is one-way: it can't be turned off on an existing project.
Why we built this#
A single Postgres instance is a well known failure point: if the database fails, your application and users are severely impacted. Traditional HA setups solve this with replicas and failover tooling, but those approaches can still lose acknowledged writes in split-brain scenarios.
Multigres treats high availability as a consensus problem. The cluster agrees on durability before acknowledging a write and resolves failovers without losing succeeded commits, while your application keeps using a single, unchanged connection string.
When building Multigres, we ran into the shortcomings of existing connection pooling approaches with Postgres. Traditionally, the pooling mode users select upfront — transaction, session, or statement — forces a trade-off between aggressively recycling connections and holding them open. This motivated us to build connection pooling that automatically selects the correct mode per query, improving user experience and laying the foundation for sharding in the future.
Known limitations in Private Alpha#
- Not covered by uptime SLA; not for production workloads.
- PITR is not currently enabled for Multigres on the Supabase platform.
- One-way enablement: cannot be added to or removed from an existing project.
- Logical replication is not currently supported, and features that depend on it, such as Supabase Realtime, are not currently supported.
- Vertical project resizing after creation (disk/CPU/memory/number of replicas) is not supported.
- Cross-region replicas are not supported — Multigres currently supports cross-AZ replicas.
FAQs#
Is it a fork of Postgres? No. Your database is standard Postgres, and Multigres handles the cluster management. Multigres verifies Postgres compatibility with the pg_regress test suite.
Do I need to change my application? No. Multigres provides a standard Postgres connection string — same drivers, same syntax, etc.
Can I lose data during a failover? No. Writes are only acknowledged once the cluster agrees they're durable via quorum-based consensus. Confirmed commits survive failover operations.
Can I enable Multigres on an existing Supabase project? No. Enabling Multigres is currently only supported at project create-time, and there's currently no managed path back to a standard Supabase project.
Is this production ready? Multigres is in Private Alpha and not covered by the Supabase platform SLAs.
Does Multigres shard my database? Not yet. This release focuses on high availability and scalable connection pooling. The same architecture is designed to support sharding.