Supabase Cost: One Project vs. Many — What Running 13 Sites Taught Me

Why This Post Exists#

I run 13 live sites — expertsapiens.com and its tenant sites, this portfolio, a handful of side projects — and every one of them touches Supabase somewhere. When people ask what Supabase actually costs to run in production, the honest answer isn't a single number. It's an architecture decision, and the decision matters more than the sticker price on any given tier.

The Free Tier Is Genuinely Fine, Until It Isn't#

Supabase's free tier gives you a real production-grade Postgres database, auth, storage, and edge functions — not a crippled trial. For a single low-traffic project, it can run indefinitely at $0. The two things that push you off it are usually the same two things everyone hits: the database gets paused after a week of inactivity (fine for a side project, not fine for anything with real users), and you outgrow the row/storage/bandwidth ceilings once actual traffic shows up.

Pro tier removes the pause-on-inactivity behavior and raises those ceilings, with additional cost scaling from there based on database compute size, storage, bandwidth, and any add-ons (point-in-time recovery, extra compute, read replicas). If you're mapping out a budget, Supabase's own pricing page has the current numbers — what I want to cover here is the decision that changes those numbers more than anything else: how many Supabase projects you actually need.

The Real Lever: One Project vs. Many#

This is the part that isn't on the pricing page. If you're running more than one site or app, you have two options:

• One Supabase project per site. Clean isolation, simplest mental model, and you pay a full Pro-tier bill (or more) per site the moment any one of them needs more than the free tier.
• One shared Supabase project across multiple sites, with tenant isolation enforced by Row-Level Security instead of by separate databases.

I run the second model. My own ops dashboard checks the health of all 13 of my live sites, and when it pings each site's Supabase instance, those 13 sites resolve down to just 5 unique Supabase projects — because most of them share infrastructure. That's not a cost hack layered on top; it's the same multi-tenant architecture I use for the ExpertSapiens platform itself, where one codebase and one database serve multiple tenant domains, and tenant context resolves from the request hostname.

The cost implication is straightforward: a shared project's paid-tier bill gets amortized across every site it serves, instead of each site independently crossing into its own paid tier. Six side projects on six separate free-tier projects is six separate pause-on-inactivity clocks and six separate ceilings to babysit. Six side projects sharing one well-configured Pro project is one bill, one set of ceilings, and — done right — one set of Row-Level Security policies doing the isolation work that separate databases would otherwise do for you.

What You Give Up for That Savings#

This isn't a free lunch, and pretending otherwise would be dishonest. Sharing a project across tenants means:

• RLS has to be airtight. Every table needs correct row-level policies, because the database boundary that used to separate two sites is gone. A missing or wrong policy on a shared project is a cross-tenant data leak, not just a bug. I wrote up the production RLS patterns I actually use for this, because it's the part that has to be right, not just working.
• Noisy neighbors are real. A traffic spike or a runaway query on one tenant can affect database performance for every other tenant sharing that project. Isolated-per-project setups don't have this problem.
• Blast radius grows. A misconfiguration, an accidental migration, or downtime on a shared project affects every site on it at once, not just one.

How I'd Decide, If I Were Starting Over#

• A single serious app with real users: its own project, full stop. Isolation is worth the extra cost the moment revenue or user trust is on the line.
• A handful of side projects, prototypes, or low-traffic tools: share a project. The free-tier pause behavior and per-project ceilings hurt more than shared-tenant risk does at that scale, as long as your RLS policies are actually correct.
• A genuine multi-tenant product (a SaaS with multiple customer organizations, or a directory platform with multiple tenant sites like ExpertSapiens): shared project, RLS-based isolation, from day one. Bolting this on after you've already shipped with per-tenant databases is a much harder migration than starting with it.

The Actual Answer to "What Does Supabase Cost?"#

For one project: whatever the current free or Pro tier costs, which you can check directly on Supabase's pricing page. For running several projects or a multi-tenant product, the number that actually matters isn't the per-project price — it's how many projects your architecture requires you to pay for in the first place. That's the decision I'd spend time on before I spent time optimizing anything else.

If you're deciding between per-tenant databases and a shared RLS-isolated project — or you've already picked one and it's starting to hurt — I've built both, and I'm glad to talk through what actually breaks at scale.

Get in touch →