Supabase Multigres private alpha: does your AI-built app need high availability yet?

On October 29, 2026, Supabase opened a private alpha of Multigres, which brings high availability to Supabase Postgres: three database nodes across availability zones with automatic failover and built-in connection pooling. For founders who built an app with Lovable, Bolt, Cursor or Replit on Supabase, the short answer is this: it's a real step toward Supabase high availability, but it's an alpha, it isn't meant for production yet, it only works on new projects, and it doesn't support Realtime or Point-in-Time Recovery. Most AI-built apps shouldn't move today. What you should do today is find out how your app would behave if the database went down for an hour, because that's the question Multigres is answering.

If your app is already live with paying users, that question is what our Care Plan is for: someone watching uptime and errors, testing that backups actually restore, and planning for the day a vendor has a bad hour. Below is what Supabase announced, what it means in plain English, and a short resilience test you can run this week.

What Supabase announced

According to Supabase's announcement, every Supabase project today writes to a single Postgres primary. If that machine has a hardware fault or its availability zone has an outage, the database is unavailable until it's recovered. That single primary stays the default.

Multigres is an open-source system for running Postgres as a cluster, built by the team behind Vitess (the system created at YouTube to scale MySQL). It isn't a fork of Postgres; your data stays in standard Postgres and Multigres manages routing, pooling, replication, failover and backups around it. Supabase released Multigres v0.1 as open source in June under the Apache 2.0 license, and this private alpha is the first time it runs on the Supabase platform.

A Multigres project in the alpha includes:

• Three Postgres nodes across availability zones in one region, so losing one zone doesn't take the database down.
• Automatic failover. If the primary fails, a replica is promoted within seconds, per Supabase.
• Built-in connection pooling with no pooling mode to choose.
• One standard connection string, so app code doesn't need to change.
• Most of Supabase: Auth, the REST Data API, Storage, Edge Functions and the client libraries work with it.

Supabase says acknowledged writes survive failover: your app only gets a "saved" confirmation once the write has been copied to enough nodes, and during failover the gateway can hold requests briefly instead of returning connection errors.

The limits that matter for AI-built apps

The alpha comes with conditions that rule it out for most live apps right now. From Supabase's own list:

• Not for production; not covered by the uptime SLA: Don't move paying customers onto it yet
• Chosen at project creation only: You can't switch on an existing project; it means a new project and a migration
• No managed path back: Once moved, returning to a standard project isn't a supported step
• No Realtime: Chat, live dashboards, presence and "live updates" features won't work
• No Point-in-Time Recovery: You get standard daily backups only
• Single region (East US, North Virginia): Users in the UK or Europe would be further from the database
• Fixed size after creation: Compute, disk and replica count can't be changed later
• Paid plans only, by request: Free-plan projects can't join; access is granted gradually

The Realtime limit is the one most likely to bite. Lovable- and Bolt-built apps often use Supabase Realtime for chat, notifications or live lists without the founder knowing it's a separate feature. If your app has anything that updates without a refresh, check before you plan any move.

Do you need Supabase high availability yet?

High availability protects against one specific failure: the database machine or its data centre zone going down. It's worth it when an hour of downtime costs you more than the effort and risk of running a more complex setup. For most early AI-built apps, three other failures are far more likely and far cheaper to guard against:

1. A bad change. An AI session rewrites a migration or a policy and breaks sign-in. Failover doesn't help; the broken change is copied to every node. 2. Deleted or corrupted data. A script or agent deletes rows. Replicas copy the deletion instantly. Only a backup you can restore helps. 3. Nobody noticing. The app is down or erroring and you learn about it from a customer.

So the honest order is: restorable backups, monitoring, and a tested recovery plan first; high availability later, when your traffic and your customers' expectations justify it.

A 30-minute resilience test for your Supabase app

Run this before you think about Multigres. None of it changes production.

1. Find your backups (5 minutes)

Open Database → Backups in the Supabase dashboard. Supabase's docs say Pro projects can access the last 7 days of daily backups, Team projects 14 days, and Enterprise up to 30. Free-plan projects aren't backed up automatically; Supabase recommends exporting regularly with the CLI's db dump and keeping copies off-site. Write down which applies to you.

2. Prove a restore works (10 minutes to start)

A backup you've never restored is a hope, not a plan. Restore the latest backup or a db dump into a separate test project, not your live one, and open a few records you know well. Check that sign-in works there too. Note how long the whole thing took: that's your realistic recovery time.

3. Check how the app fails (5 minutes)

In a test project or local copy, point the app at a database that isn't reachable and open the main screens. Does it show a clear "we're having trouble" message, or a blank screen, endless spinner or raw error? Users forgive an outage they understand far more readily than a broken page.

4. Make sure someone hears first (5 minutes)

Subscribe to Supabase's status page for your region, and set up a simple uptime monitor that checks a page needing the database. Send alerts to a phone or inbox someone actually reads.

5. Write the one-page plan (5 minutes)

Who checks first, where the backups are, how to post a status update to users, and when you'd restore versus wait. One page is enough.

If you do want to try Multigres

If you have a paid organisation and a new, non-critical project that doesn't use Realtime, the alpha is a reasonable way to learn how failover behaves before it's generally available. Supabase says it's free during the alpha for up to two projects per organisation and that pricing may change after. Request access through the form linked in the announcement; the High availability toggle only appears in Create a new project once your organisation is invited. Keep production where it is until Supabase says the feature is ready for it.

If your real concern is scale rather than uptime, Supabase's existing read replicas are a separate, generally available option for spreading read traffic. They copy data asynchronously, so they aren't the same as automatic failover. And if you're weighing control and cost more broadly, our guide to what self-hosting Supabase actually includes explains why running Postgres yourself makes availability your job, not Supabase's. For a quick read on overall launch readiness, try the free launch-ready self-check, and see our production checks for an AI-built app for the basics before real users arrive.

Practical takeaways

• Multigres (private alpha, announced October 29, 2026) adds three-node Postgres with automatic failover to Supabase.
• It's not for production yet, only for new projects, with no Realtime and no Point-in-Time Recovery.
• For most AI-built apps, tested backups and monitoring matter more than high availability today.
• Restore a backup into a test project this week and time it.
• Revisit Multigres when it leaves alpha and your downtime cost justifies it.

FAQ

Does Supabase have high availability?

Standard Supabase projects run on a single Postgres primary. Multigres, in private alpha since October 29, 2026, adds a three-node cluster with automatic failover for new projects on paid plans, but Supabase says it isn't for production during the alpha.

Can I turn on Multigres for my existing Supabase project?

No. During the alpha it can only be chosen when a project is created, and there's no managed path back to a standard project.

Will Multigres work with my Lovable app?

Auth, the REST API, Storage, Edge Functions and the client libraries are supported, so many screens would work. Anything using Supabase Realtime, such as chat or live updates, won't work during the alpha.

---

Running a live app and not sure how it would cope with a database outage, a bad deploy or a deleted table? Our Care Plan covers uptime and error watching, tested backups, security updates and cost reviews in a plain-English monthly note. Book a free technical assessment and we'll tell you where your app is most exposed today.