Supabase's Self-Hosted Break-Even Isn't 200,000 Users — It's 200 Dollars a Month

Search "when should I self-host Supabase" and the same folk number keeps showing up: wait until you have 200,000+ users, or 200GB of data, then make the jump. It's a tidy rule of thumb, and it's the wrong axis entirely. User count doesn't determine your Supabase bill — compute tier, egress, and storage do, and those three inputs can push a 5,000-user realtime app past the self-hosting break-even long before it hits six figures of signups, while a lean 300,000-user API-only app can sit comfortably under $75/month on Cloud the whole way.

The number that actually matters is a dollar figure, not a user count, and it's smaller than most teams assume: roughly $200/month in Supabase Cloud spend — but only for a team that already runs infrastructure and can absorb one more Postgres stack into existing ops. For a team standing up self-hosting from zero, the real crossover is much higher. Here's the worked math for both.

The Worked Crossover​

Self-hosting Supabase's stack (Postgres, GoTrue, PostgREST, Realtime, Storage) costs two things: a box, and the time to run it. The box is cheap — a Hetzner instance with enough RAM for the Docker Compose stack runs $10-20/month. The time is where the two scenarios diverge hard.

Scenario A — starting from zero ops capacity. A team with no existing self-hosted infrastructure has to build monitoring, backups, upgrade procedure, and incident response from scratch. Community estimates for a healthy self-hosted Supabase deployment land at 5-10 hours/month in ongoing maintenance, plus 8-16 hours of one-time setup. At a conservative $100/hour, that's $500-1,000/month in labor before counting the box.

Scenario B — already running a self-hosted PaaS. A team that already operates infrastructure — existing monitoring, existing on-call, an existing Kubernetes or Cluster-API fleet — isn't building ops capacity from scratch. It's adding one more workload to a system that already has dashboards, alerts, and a patching cadence. That marginal cost is closer to 1-2 hours/month: applying a Postgres minor version bump, checking a disk-usage alert. Call it $100-200/month in labor.

Two crossovers fall out of that table, and they're not close to each other. Scenario B crosses right around $200/month — exactly the number the "bring your own Postgres" conversation keeps landing on. Scenario A doesn't clearly cross until Cloud spend is pushing $600-1,100/month, and even then only at the low end of the labor estimate. For most teams without existing ops capacity, self-hosting Supabase to save money is a trap: the infrastructure bill goes down and the labor bill more than eats the difference.

The practical read: the $200/month number is real, but it's conditional on already being an infrastructure-operating team — which is exactly the situation a team running a self-hosted PaaS is already in.

Concretely: a collaboration app with 5,000 active users, live cursors and presence over Realtime, and user-uploaded attachments in Storage doesn't look like a "small app" on Supabase's meter even though it's nowhere near 200,000 signups. Realtime connections and Storage egress are exactly the two line items that blow past the pooled 250GB fastest, and a Medium compute tier to keep query latency sane under concurrent connections adds $60/month on its own. That combination lands in the $200-300/month range well before user count would suggest self-hosting is even worth discussing under the old folklore.

What Actually Drives a Supabase Cloud Bill From $25 to$300​

The $25/month Pro plan is a floor, not a typical bill. It bundles a $10 compute credit that covers exactly one Micro instance (1GB RAM) — fine for a side project, tight for anything with real traffic. Three things push the number up from there:

• Compute tier. Supabase's dedicated compute add-ons scale from Micro ($10/mo, already covered by the Pro credit) through Small ($15), Medium ($60), Large ($110), XL ($210), and up into four figures at the top end. A growing app on Small compute with 20GB of storage and 300GB of egress lands around $36/month — already 44% above the sticker price.
• Egress. Pro includes a pooled 250GB of egress across database and storage traffic. Past that, both are metered at $0.09/GB (cached egress is cheaper, at $0.03/GB). A media-heavy app or one with a chatty realtime layer can burn through 250GB fast.
• Storage. Billed separately from egress, and it compounds with compute tier — a Medium-compute app with meaningful file storage and cross-region egress is what actually produces the $150-300/month bills that trigger the self-hosting conversation.

Put together, that's why "real-world Supabase costs $35-75/month for small-to-medium apps" and "self-hosting pays off around $200/month" are both true statements about the same product — the gap between them is exactly the compute-tier-plus-egress growth curve above.

What the Self-Hosted Stack Actually Costs to Run​

The infrastructure side of the self-hosted number is genuinely cheap, which is why the labor line dominates the decision. Supabase's self-hosted stack is a Docker Compose deployment of roughly 15 containers — Postgres, GoTrue (auth), PostgREST (the auto-generated REST API), Realtime, Storage, Kong (API gateway), Studio, and support services — needing 3-4GB of RAM at idle. A Hetzner box with 8GB RAM runs under €8/month (roughly $8.50 USD), comfortably covering the stack with headroom for actual data growth.

The egress side flips the self-hosted math even further in its favor. Hetzner includes 20TB of outbound traffic on most Cloud plans; a database-heavy app serving 500GB/month of egress costs nothing extra on Hetzner but would add real dollars on a cloud provider metering per gigabyte. That's the same dynamic that makes a self-hosted PaaS's own bandwidth story attractive — it's not a coincidence that "the database sitting next to a self-hosted app" and "the app itself" both get cheaper on owned hardware for the same structural reason: no per-GB meter.

None of that changes the labor math from the section above, though. A $10/month box that needs 8 unplanned hours of debugging after a botched Postgres upgrade is not a $10/month decision — it's whatever those 8 hours are worth, which is exactly why Scenario A and Scenario B produce such different answers from the same infrastructure cost.

The line item community cost breakdowns tend to undercount is backups and high availability, and it's also the line item that explains most of the Scenario A/B gap directly. Point-in-time recovery, WAL archiving, and failover aren't things docker compose up gives you for free — a team starting from zero has to design and test that recovery path itself, which is exactly the kind of unplanned, error-prone work that turns a "5 hours a month" estimate into 15 the month a disk fills up. A team already running Postgres operators on an existing Kubernetes fleet has usually already solved backups and failover once, generically, for every database on the fleet — so the marginal database inherits a recovery path instead of needing its own.

Why the Marginal Path Is the Realistic One​

bex treats managed databases as an explicit non-goal — it's not building a hosted Postgres product, and it isn't going to. That means every bex tenant with a database is already living the "bring your own Postgres" story, running something like CloudNativePG as a Kubernetes operator alongside their app, on the same Cluster-API-managed fleet that's already running their deploys.

That's precisely Scenario B. A team that's already operating a self-hosted PaaS has already paid the fixed cost of monitoring, backups, and on-call — the CNPG operator managing a Postgres instance is one more CRD reconciled by infrastructure that already exists, not a new discipline learned from scratch. The 1-2 hours/month in Scenario B isn't a hypothetical; it's what "the database is one more workload on a fleet you already run" looks like in practice.

This is also why "200,000 users" was never the right threshold. A bex tenant with 5,000 users generating heavy Realtime and Storage traffic can cross $200/month on Supabase Cloud well before six figures of signups — and for that tenant, self-hosting the database next to an already-self-hosted app is the cheaper, lower-friction path immediately, not a someday migration. The trigger was always spend against existing ops capacity, not a user-count milestone borrowed from a different kind of scaling conversation.

The Decision Rule​

Skip the user-count folklore. Two questions settle it:

1. Does your team already operate infrastructure — an existing self-hosted PaaS, an existing Kubernetes fleet, existing on-call? If not, stay on Supabase Cloud until the bill is genuinely painful (well north of $500/month), because the labor cost of building ops capacity from scratch dwarfs any infrastructure savings below that.
2. If yes, is your Supabase Cloud bill approaching or past $200/month? That's the point where the marginal cost of running Postgres, GoTrue, PostgREST, Realtime, and Storage alongside infrastructure you already operate drops below what Cloud charges for the same stack.

For everyone else, the honest answer is the same one the CNPG-vs-Zalando-vs-StackGres comparison already reached: self-hosting the data layer is a genuine option once you're already running the app layer yourself — it was never about how many users signed up.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, and bring your own Postgres via CloudNativePG on the same fleet instead of paying a second vendor's metered database bill. Star the repo on GitHub or deploy your first app today.

Sources:

• Supabase Pricing.
• Supabase Docs: About billing on Supabase.
• Supabase Docs: Manage Egress usage.
• Supabase Pricing in 2026: What You'll Actually Pay.
• The True Cost of Self-Hosting Supabase: A Breakdown.
• Self-Hosted vs Cloud Supabase for SaaS 2026.
• Hetzner Cloud Pricing.
• Hetzner Docs: Traffic.