No vendor writes the TCO comparison between Supabase Cloud and self-hosted. The reason is simple: the honest calculation comes out clean for neither side, and a vendor only earns money on one of the two answers.
Over the past few years Supabase has gone from insider tip to a default building block in many modern stacks. Postgres, Auth, Storage, Realtime, Edge Functions — wired together, productive in minutes. That very convenience pushes the real decision into the background: what does Supabase actually cost over three years if the project succeeds? Not in month one, but in the month when a thousand users turn into a hundred thousand. Ask that question only when the first four-figure invoice lands, and you asked it too late.
What Supabase Cloud really costs — and why the base prices tell you little
The official pricing page is refreshingly transparent, as long as you read it closely. Supabase Cloud has four tiers: Free at 0 USD, Pro from 25 USD/month, Team from 599 USD/month, and Enterprise on custom terms (as of mid-2026, Cloud prices shift often — verify in the configurator). The word that matters sits in small print beside the number: "from". The Pro plan is not a fixed price, it is a starting price.
What the 25 USD covers is concrete: 10 USD of compute credit, enough for a Micro instance, 8 GB disk per project, 100,000 monthly active users, and 250 GB of egress. Sounds generous, and for many projects it is. The point is what happens *after* that. Egress costs 0.09 USD per GB, disk 0.125 USD per GB, each additional active user 0.00325 USD. Compute is a separate add-on, billed hourly, from Micro at roughly 10 USD/month up to 16XL at around 3,730 USD/month (the add-on table changes more often than the base prices — read it as an order of magnitude, not a fixed value).
This is not a complaint about the pricing. It is honestly usage-based. But that is exactly the mechanism FinOps owners need to grasp: the cost of managed services rises with the project's success. More users, more traffic, more data, higher bill — not linearly, but along thresholds you only notice in the configurator once you cross them. Build something that works, and you penalise yourself on the infrastructure side.
Hetzner and Supabase self-hosted: the calculation no salesperson runs for you
Supabase is fully self-hostable. All the core components — Auth via GoTrue, PostgREST, Storage, Realtime, Kong as the gateway, Postgres itself — run on your own infrastructure via Docker and Docker Compose. The main repository is Apache-2.0; the components sit under MIT, Apache-2 and PostgreSQL licences. No licensing trick, no hidden enterprise gate barring the door. What Supabase Cloud runs, you can in principle run yourself.
Let's work it through with real numbers instead of glossy ones. A Hetzner AX41-NVMe — AMD Ryzen 5 3600, 64 GB RAM, two NVMe SSDs, unlimited traffic — sits at around 39 €/month net. The defensible 2026 range runs from roughly 37 to 51 € depending on location, with an announced price adjustment for 15 June 2026 and an upward trend — check the live price in the Hetzner configurator. On this single machine, database, auth, storage and API for an application with a few thousand active users run comfortably.
Two line items quietly get dropped on top. First, a clean initial implementation: setup, integration, security hardening, testing — a one-off 5,000–20,000 € of development effort, depending on complexity and compliance requirements. Second, ongoing operation: with sensible automation, 2–5 hours per month for updates, monitoring and backups. These hours are predictable — that is their decisive trait. They don't swing with the traffic.
Over three years, a typical mid-sized web application on a self-hosted open-source stack tends to land at 40,000–80,000 €, setup and operation included. A comparable setup on proprietary managed services often runs at double over the same window, sometimes more. We see the same pattern across industries — in a TCO comparison of WordPress against Sanity and Next.js, or in the more basic question of what a modern company website really costs. The core sentence holds: the cost of a self-hosted stack falls per user over time; the cost of managed services rises with the project's success.
Why the curves cross — and where
Thinking of both models as straight lines is the most common mistake. They are not straight lines. They are two curves with different slopes.
Supabase Cloud starts cheap, almost free. The Free plan covers 500 MB of database, 50,000 MAUs and 5 GB of egress — but pauses after a week of inactivity, so it only suits prototypes. The Pro plan carries surprisingly far. In a project's first months, Cloud is simply cheaper than any self-hosted alternative, because there are no setup costs and nobody is investing operating hours. Then the curve climbs. Every growth spurt brings egress, compute and MAU overages with it.
Self-hosting starts expensive. The 5,000–20,000 € of setup stands at the very beginning, before the first user has logged in. After that the curve flattens. Whether the AX41 carries a thousand or twenty thousand users barely changes the hardware cost — a dedicated server scales vertically for a good while before you start thinking about redundant instances and a separate DB layer (realistically 150–400 €/month for genuine high availability).
The crossover isn't a fixed date but a usage and data profile. Rule of thumb from practice: once egress and compute on the Cloud bill exceed the fixed Hetzner cost plus the monetised maintenance effort — and the project has left the prototype stage — the balance tips toward self-hosted. For data-intensive applications with heavy egress or many active users, that happens earlier than most expect. For an internal tool database with modest traffic, perhaps never.
Self-hosted means operational responsibility — and that costs
Here it gets honest. Self-hosting is not a button you press and forget. It is operational responsibility: applying updates, rolling out security patches promptly, testing backups — not just creating them, testing them — setting up monitoring, running a restore at 3 a.m. when it counts. That responsibility doesn't vanish with managed services; it moves to the provider. That is precisely what the premium pays for.
If you can't or won't cover that responsibility in-house, you should seriously consider managed. The logic is symmetric: with managed, cost rises and effort falls. With self-hosted, cost falls and effort rises. Neither option minimises both at once. Anyone promising that is selling something.
That's also why we don't recommend self-hosting to everyone who asks. A stack that needs an authenticated login with its own identity provider — the kind of Supabase-plus-Keycloak combination I've costed out in detail elsewhere — adds further operational components that someone has to understand and maintain. Operational responsibility is not a footnote. It is half the decision.
The uncomfortable point: the hour nobody books
Now to the part most TCO calculations dress up. The self-hosting saving is only real if your own operating hours enter the math at a real hourly rate.
I see it regularly: a CTO weighs the hardware against the Cloud bill and arrives at a tidy saving. What's missing is their own time and their team's. The 2–5 hours of monthly maintenance are not a free resource. At a realistic blended rate of around 120 € per developer hour, that's 240 to 600 € a month that has to appear in an honest balance. Counting those hours as zero rigs the result — only to your own disadvantage, because the surprise arrives later.
And it doesn't arrive in the average. It arrives in the exception. The average is two quiet hours a month. The exception is the night a failed update takes the database down and someone has to restore the backup — someone who knows how, and who is reachable. That one night appears in no spreadsheet, but it is real. Choosing self-hosting buys you not just servers but the obligation that this competence exists in-house and is available. Price it in, and the saving shrinks — and for small projects it tips into the opposite.
This is exactly where my own thesis has its limit. Self-hosting is not categorically cheaper. It is cheaper above a threshold, *and* on the condition that the operational competence is already there or is to be deliberately built. Remove that condition, and the apparent saving is an accounting illusion.
The legal dimension that's in no price table
One factor bursts TCO in the narrow sense but belongs to the overall decision: where the data lives. Supabase Cloud runs on AWS, with the region selectable per project — Frankfurt, Paris, Zurich, Stockholm and other EU locations are available. That doesn't fully resolve the GDPR question. Supabase Inc. remains US-incorporated and therefore potentially subject to the US CLOUD Act, regardless of the EU storage location. That's a legal reading drawn from secondary sources, not an infrastructure limitation — but for regulated industries it's a line item in vendor risk management. Run it self-hosted on German hardware and the question is off the table.
This isn't a Cloud-only problem. Every US provider carries the same tension, which is why the comparison of Supabase against Firebase from a European perspective comes out even sharper for Firebase: no self-hosting, Google Cloud only. The sovereignty question is part of the make-or-buy decision, not a downstream compliance detail. If you're coming from an existing Firebase base, the guide to migrating from Firebase to Supabase covers the technical pitfalls — but the cost question is settled before that.
What I tell decision-makers
Calculate both curves, not both straight lines. Set a realistic growth scenario — not this month, but the month when the project works — and enter the Cloud usage line items just as carefully as the Hetzner fixed costs and your own operating hours at a real rate. Set your own time to zero and you're kidding yourself, and the truth arrives at night.
For an early project without an ops team, Supabase Cloud is the right answer — fast start, no operational load, predictable up to the first real scaling. From the point where the project carries, where egress and compute become noticeable and the operational competence is in-house or meant to be, the balance turns. Then self-hosted on Hetzner is not only cheaper but also more sovereign. The strategic logic that hosting decisions say more about an application than performance alone applies here twice over. If you want to run Supabase without vendor lock-in and understand the depth of the stack, the Supabase hub for decision-makers sets it in context. The question is never whether managed or self-hosted is cheaper *in general*. The question is where on your growth curve you stand right now — and whether you calculate honestly enough to see it.
