Is Supabase Production Ready in 2026?
Vasim Gujrati
Solutions Architect, AI & Platforms, Unico Connect
In this article
Supabase is a hosted Postgres database with authentication, storage, realtime, and edge functions wrapped around it. The question is not whether it works, because plenty of real companies run on it at scale. The question is whether it fits your workload, and where the walls are so you meet them on purpose instead of during an incident. This guide gives the honest version, grounded in what Supabase itself publishes about its limits.
Quick Answer
Yes, Supabase is production ready for most web and mobile applications, and companies have taken it from zero to over a million users. It is standard Postgres underneath, it holds SOC 2 Type 2, HIPAA, and ISO/IEC 27001:2022 compliance, and it offers point in time recovery, read replicas, and log drains on paid plans. The real limits are specific rather than general. Vertical compute stops at 64 cores, so extreme write throughput has no managed sharding answer yet. Read replicas scale reads only, not writes, and there is no multi region write option. The most common production surprises are the two email per hour auth limit on the built in mailer, connection exhaustion without the pooler, and egress bills on media heavy apps. An uptime service level agreement exists only on the Enterprise plan. For the large majority of products none of these are blockers, and the ones that bite are usually fixed in place rather than by migrating.
Key Takeaways
- Supabase is production grade Postgres, not a toy. SOC 2 Type 2, HIPAA on paid plans, ISO/IEC 27001:2022 since 2026, point in time recovery, and read replicas are all available.
- The limits are specific, not vague. Compute tops out at 64 cores and 256 GB, read replicas serve reads only, and there is no multi region write today.
- Most scaling pain is self inflicted and fixable. Connection exhaustion, slow row level security, and rate limited auth emails all have known fixes that do not involve leaving.
- The classic surprise bills are egress and the free tier pause. Media heavy apps pay for bandwidth, and free projects pause after a week of inactivity.
- Fix in place before you migrate. Indexes, the connection pooler, custom email, and a CDN in front of storage solve the common problems for a fraction of the cost of a rebuild.
Who Actually Runs Supabase in Production
The best evidence that Supabase holds up is the companies that depend on it. Supabase publishes customer stories with numbers behind them. Pebblely reached a million users in seven months. Mobbin migrated two hundred thousand users off Firebase. Humata scaled to millions of users while cutting its vector database cost. Supabase also reports that a dozen companies went from zero to more than a million users on the platform inside a single year, and its enterprise logos include Mozilla, PwC, and 1Password. This is not a platform that falls over at the first sign of traffic. It is a platform with a shape, and the job is to know the shape.
What Does Production Ready Actually Require
Production readiness is not one feature. It is recovery, observability, compliance, and a support commitment. Here is where Supabase stands on each, from its own documentation.
Recovery is covered by point in time recovery, available as an add on for Pro plans and above, which archives the write ahead log every two minutes so your worst case data loss window is around two minutes. It needs at least the Small compute size, and turning it on replaces the default daily backups. Observability comes through log drains on paid plans, which ship your logs to destinations like Datadog, Sentry, S3, and others. Compliance is strong, with SOC 2 Type 2, HIPAA available on the Team plan and above with a signed business associate agreement, and ISO/IEC 27001:2022 certification added in 2026.
The one place to read the fine print is the service level agreement. A committed uptime guarantee, the 99.9 percent number, exists only on the Enterprise plan. The Pro and Team plans give you support response time commitments, not an uptime promise. If a contractual uptime figure matters to your business, that decision points at Enterprise.
Where Are the Real Scaling Limits
These are the walls that actually exist, with the numbers Supabase publishes.
The Vertical Ceiling
Supabase scales compute up to a 16XL instance, which is 64 cores and 256 GB of memory. That is a large machine that most applications never approach. But it is a ceiling, and past it there is no managed sharding. Supabase is building Multigres, a sharding layer for Postgres, and released an early alpha in 2026, but it is not yet a managed feature you can turn on. So a workload with extreme sustained write throughput that would outgrow 64 cores does not have a Supabase native answer today. This is the single clearest case for looking elsewhere, and it applies to very few products.
Reads Scale, Writes Do Not
Read replicas are available on paid plans, up to two below the XL compute size and up to five at XL and above. They are asynchronous copies that serve read only traffic, and they can sit in other regions to cut latency for a global audience. The important caveat is that they scale reads only. Writes still go to a single primary, and Auth, Storage, and Realtime cannot use replicas at all. There is no multi region write setup on the platform. For read heavy apps this is a strong scaling lever. For write heavy or write distributed apps it is not the answer.
Connections Are Finite and the Pooler Is the Fix
Every compute size has a hard cap on direct database connections, from 60 on the smaller instances up to around 500 at the very top. Serverless and edge environments open connections fast and can exhaust that budget quickly. The fix is built in. Supabase runs a connection pooler called Supavisor, and paid plans also get a dedicated pooler beside the database. Pooled client connections run far higher than direct ones, into the thousands on larger instances. Connection exhaustion is one of the most common production complaints and one of the most avoidable, because it is a configuration choice rather than a platform limit.
Row Level Security Has a Performance Cost You Can Remove
Row level security is evaluated for every row a query touches, and a naive policy re evaluates the auth function once per row. Supabase documents the fix, and it is dramatic. Wrapping the auth call so it reads as a subquery lets Postgres evaluate it once per statement instead of once per row, and adding an index on the column your policy filters shows more than a hundred times improvement on large tables in Supabase own benchmark. Slow queries under heavy row level security are almost always a policy that was never optimized, not a reason to abandon the model.
What Are the Surprise Bills and Footguns
Some of the sharpest production lessons are about cost and defaults rather than raw scale.
The free tier pauses a project after one week of inactivity. That is fine for experiments and a problem if a low traffic production app sits on the free plan, because the first visitor after a pause meets a cold start. Production apps belong on a paid plan where projects do not pause.
The built in email service sends only two emails per hour. This is not a bug, it is a deliberate limit to stop the shared mailer being abused, and it is the most common auth footgun in existence. Any real app must connect a custom SMTP provider, after which the limit is yours to set. Most Supabase rate limiting that people hit lives on the auth endpoints, not on the data API.
Egress is the bill that surprises media heavy apps. Bandwidth past the included allowance is charged per gigabyte, and an app serving lots of images or video can run up a real number. The fix is a content delivery network in front of storage, which turns most of that traffic into cheaper cached egress. Edge functions also have limits worth knowing before you lean on them. They cap at 256 MB of memory and a couple of seconds of CPU time, so they are built for quick request handling, not long running jobs or heavy image processing.
One recent change works in your favor. Since the middle of 2026, new tables in the public schema are no longer automatically exposed through the data API. Access has to be granted explicitly, which closes a class of accidental exposure that used to catch teams by surprise. If security is on your mind, our Supabase RLS security checklist is the companion to this guide.
Should You Fix in Place or Migrate Off
When a Supabase app struggles, migrating is rarely the first right move. Supabase publishes its own guidance here, and it lines up with what we see in practice. Run explain analyze and add indexes before you buy a bigger machine. Move to the connection pooler before you blame connection limits. Connect custom email before you fight the two per hour cap. Put a content delivery network in front of storage before you panic about egress. Optimize row level security policies before you conclude the database is slow. Each of these is cheaper than a rebuild and usually enough.
Migrating off makes sense in a smaller set of cases, and they are worth naming precisely.
You need more control over the code and the runtime. On the managed platform your server side logic runs inside Supabase edge functions, which are Deno based and deliberately constrained. That is fine for quick request handling and webhooks. It is limiting the moment you want a different language, a long lived process, background workers, or libraries the runtime does not allow. Moving that logic to a backend you own, on your own infrastructure, trades convenience for full control over how the code runs.
Some workloads simply do not fit edge functions. The limits are specific. An edge function gets about two seconds of CPU time and a couple of hundred megabytes of memory per request, so anything genuinely heavy struggles. Image and video processing is the clearest example, and Supabase own guidance is to push that kind of work to a dedicated service rather than run it in a function. Long running jobs, large batch processing, and CPU bound computation all belong on a purpose built worker, not on the edge runtime.
You are optimizing for cost and speed at scale. A managed platform carries a margin over raw infrastructure, and egress in particular is priced per gigabyte. For a high traffic or media heavy product, running your own Postgres and moving compute onto infrastructure you tune directly can lower the bill and cut latency, because you control instance sizing, caching, and where each piece of the workload runs. Below real scale this rarely pays off, since managed convenience is worth more than the savings. Past it, the math can flip.
You have outgrown the platform ceiling. If your sustained write throughput approaches the top compute size with no sign of slowing, and you need sharding that the managed platform does not yet offer, that is a real reason, as is a requirement for multi region writes, which the platform does not support. And there is the case a well known engineering team wrote about years ago, where a product used Postgres as a plain persistence layer and none of the Auth, Realtime, or Storage features. That account is dated now and several of its specific complaints predate current backup and recovery features, but the logic holds. If you use none of what makes Supabase Supabase, you may not need Supabase.
Worth remembering through all of this, it is standard Postgres, so a clean exit through a database dump is always available. That escape hatch is itself part of the production readiness argument.
How We Decide With Clients
When a team asks us whether to stay on Supabase or move, we do not answer from preference. We profile the workload, read the slow queries, check the connection and pooler setup, look at where the cost is actually going, and measure the row level security overhead. In most cases the app is production ready and the pain is a handful of fixable configuration choices. In the few cases where the workload genuinely exceeds what the platform offers, we plan a migration that keeps the Postgres data intact rather than a rewrite. If you have built on Supabase and hit a wall, our MVP build and rescue service includes a free architecture audit, and you can hire a Supabase developer from our team to do the work.
Frequently Asked Questions
Is Supabase good enough for a production app?
For most web and mobile applications, yes. It is managed Postgres with authentication, storage, and realtime, it carries SOC 2 Type 2, HIPAA, and ISO/IEC 27001:2022 compliance, and companies have scaled it past a million users. The limits that matter are specific, mainly around extreme write throughput and multi region writes, and they do not affect the majority of products.
What are the main Supabase scaling limits?
Compute scales up to 64 cores and 256 GB, which is a ceiling with no managed sharding beyond it yet. Read replicas scale reads only, not writes, and there is no multi region write option. Each compute size caps direct database connections, though the built in pooler raises the usable number substantially.
Why is Supabase only sending two emails per hour?
That is the rate limit on the built in shared email service, and it is intentional. Production apps are expected to connect their own SMTP provider, after which you control the sending limits. It is the most common auth issue teams hit and it is a configuration fix, not a platform flaw.
Does Supabase have an uptime SLA?
A committed uptime service level agreement, the 99.9 percent figure, is available only on the Enterprise plan. The Pro and Team plans include support response time commitments rather than a contractual uptime guarantee.
When should I migrate off Supabase instead of fixing it?
Migrate when your workload genuinely exceeds the platform, such as sustained write throughput beyond the largest compute size with a need for sharding, or a requirement for multi region writes. Also consider it if you use Postgres purely as a persistence layer and none of the Auth, Realtime, or Storage features. In most other cases, indexing, pooling, custom email, and a CDN solve the problem in place.
Can Supabase handle high traffic?
Read heavy high traffic scales well with larger compute and read replicas, including across regions. Write heavy traffic is bounded by the single primary and the top compute size, since there is no managed sharding yet. Knowing which kind of traffic you have is the key to answering this for your own app.
