- The four separate meters that make up every Supabase invoice
- Why compute, not the plan fee, is the line item that scales fastest
- How a single $25 Pro project realistically bills at $97 in a busy month
- The free-tier limits that matter and the ones that do not
- When usage-based pricing is genuinely the cheaper choice, and when flat pricing wins
- Which alternatives are worth pricing against Supabase, and for which workload shape
Supabase publishes a clear pricing page, and people still get surprised by the invoice. That is not because the page is dishonest. It is because the headline number is a floor, not a price. A $25 plan can bill $97 without anything unusual happening.
The confusion is structural. Supabase bills on four separate meters, and only one of them is fixed. Understanding which meter moves fastest is the whole game.
The four meters on a Supabase bill
Every Supabase invoice is the sum of four independent things:
The plan fee - charged per organisation. Free, Pro at $25 per month, or Team at $599 per month.
Compute - charged per project. Each project runs on its own Postgres instance, and each instance has a size.
Egress - charged per GB of data leaving Supabase, past the allowance included in your plan.
Database storage - charged per GB of disk, past the allowance included in your plan.
Read that list again and notice the mismatch: the plan is billed per organisation, but compute is billed per project. That single asymmetry causes most of the surprise. Adding a project does not upgrade your plan, so nothing warns you. It simply adds a recurring compute line.
Plan fee: the smallest number on the invoice
The Free plan gives you 500 MB of database, 50,000 monthly active users, and projects that pause after a week without activity. It is a genuinely good prototyping tier and a genuinely bad production tier, mostly because of the pausing.
Pro costs $25 per month per organisation and includes 8 GB of database disk per project, 250 GB of egress, 100,000 monthly active users, and a $10 compute credit. Team costs $599 per month and mainly buys compliance features, longer log retention, and support commitments rather than more capacity.
For most teams the plan fee is the least interesting line on the bill. It is a rounding error next to compute.
Compute: the line item that surprises people
Every Supabase project is a Postgres instance, and instances come in sizes. The Pro plan's $10 compute credit covers exactly one Micro instance. Your first project therefore feels free. Your second does not.
Instance | Approx. monthly cost | Memory | Typical use |
|---|---|---|---|
Micro | $10 | 1 GB | One low-traffic project. Covered by the Pro credit. |
Small | $15 | 2 GB | A production app with modest concurrency. |
Medium | $60 | 4 GB | Steady traffic, several hundred connections. |
Large and above | Rises steeply | 8 GB+ | Sustained load, heavier analytical queries. |
Two things matter here. First, compute does not scale to zero on Supabase the way it does on a serverless database, so an idle staging project still bills. Second, the credit is per organisation, not per project. Four projects on Micro cost roughly $40 in compute, of which $10 is credited. Nobody upgraded a plan, and the bill went up by $30.
If you keep separate projects for production, staging, and preview environments - which is exactly what Supabase's own documentation encourages - you are paying compute three times.
Egress and storage: the meters that grow with success
Egress is every byte your users pull out: API responses, realtime messages, and files served from Supabase Storage. Pro includes 250 GB per month, and past that you pay roughly $0.09 per GB. For a JSON API that is generous. For an app that serves images or video from Supabase Storage, 250 GB is a fortnight.
Database storage is billed at roughly $0.125 per GB past the 8 GB included per project. That sounds trivial until you remember that Postgres disk usage includes indexes, bloat, and write-ahead logs, not just the size of your rows. A 4 GB dataset can occupy considerably more disk than 4 GB.
The cheapest byte is the one you never send. Egress overages are almost always a caching problem before they are a pricing problem.
A worked example: the $25 plan that bills $97
Consider an ordinary team: one production project, one staging project, an app that serves user-uploaded images, and eleven months of accumulated rows.
Plan fee (Pro, per organisation) $25.00
Compute
production project Small (2 GB) $15.00
staging project Micro (1 GB) $10.00
compute credit included with Pro -$10.00
three preview branches, Micro, part-month $20.00
-------
$35.00
Egress
420 GB used, 250 GB included
170 GB x $0.09 $15.30
realtime + storage reads $2.70
-------
$18.00
Database storage
disk 160 GB across projects, 16 GB included
144 GB x $0.125 $18.00
point-in-time recovery add-on $1.00
-------
$19.00
TOTAL $97.00
No line item here is unfair, and none of them is hidden. The problem is that four meters moved at once, each for a defensible reason, and the plan page only advertised one number.
Where Supabase pricing genuinely wins
Usage-based pricing is not a trick. It is the correct model for a specific shape of workload, and if that is your shape you should take the deal:
A single project with spiky, unpredictable traffic. You pay for the spikes and nothing else.
Prototypes and demos, where the free tier's pausing behaviour is irrelevant.
Teams that genuinely want the whole bundle - Postgres plus auth, storage, realtime, and edge functions behind one SDK.
That bundle is real value. If you are replacing four services with one, comparing Supabase's bill to a bare database's bill is not a fair comparison. We wrote about exactly where that trade lands in our Neon vs Supabase comparison.
The alternatives worth pricing against Supabase
The model inverts when your workload is steady and plural. Several projects, each with predictable traffic, each running a compute instance that never idles down, is the worst case for per-project metering. That is the point to price alternatives - and they are not all the same kind of thing.
Alternative | Billing model | Best when | Trade-off |
|---|---|---|---|
Neon | Serverless compute, scales to zero | Spiky or intermittent traffic, many branches | Cold starts; compute still meters under load |
Firebase | Per document read / write | Mobile-first apps needing offline sync | Document model; proprietary export format |
AWS RDS | Instance + storage + IOPS + transfer | You already live inside a VPC | Substantial operational and networking overhead |
Self-hosted Supabase | Server cost only | You have ops capacity and want the bundle | Ten coupled services to upgrade and back up |
Swyftstack | Flat monthly plan | Several steady projects, predictable invoices | Worse value than metering for idle workloads |
Disclosure: Swyftstack is our product, so treat the last row with the scepticism it deserves. Here is the arithmetic rather than the adjective. Our Launch plan is $19 per month and includes three projects, three databases, 10 GB of database storage, 200 GB of object storage, and 500 GB of egress. Growth is $99 and covers 15 projects, 50 GB of database storage, and a terabyte of object storage. There is no per-project compute line, because compute is not the meter. The plan is.
That is a worse deal than Supabase for one spiky project and a better one for five steady ones. We would rather say that plainly than pretend flat pricing is universally cheaper. If you want the full landscape rather than our version of it, our roundup of Supabase alternatives covers the other options honestly, our Neon vs Supabase comparison digs into the serverless option, and managed Postgres explains what we actually provision.
How to forecast your own bill
Do it in this order, because this is the order of magnitude:
Count projects, not users. Multiply projects by compute tier. Include staging and preview environments. This is usually more than half your bill.
Estimate egress in GB. Take your monthly API response bytes plus anything served from object storage. If you serve media, this number is larger than you think.
Measure real disk, not row count. Run a size query against your existing database and add roughly 30 percent for indexes and bloat.
Only then compare plans. Against Supabase, against a flat provider, against a VPS you administer yourself. The winner changes with the shape of your workload, not with the brand.
Prices quoted here were checked in July 2026. Vendors change them; treat the structure as the durable part and re-check the current numbers before you budget.
Frequently asked questions
Is the Supabase free tier enough for production?
Rarely. The free tier caps the database at 500 MB and pauses projects after a week of inactivity. It is excellent for prototypes and demos. The moment real users depend on the database, the pausing behaviour alone disqualifies it, and 500 MB fills faster than most people expect once you add indexes and a few months of rows.
Why is my Supabase bill higher than $25 when I am on the Pro plan?
Because the Pro plan is a minimum. It includes a compute credit that covers the smallest instance for one project, 8 GB of database disk, and 250 GB of egress. A second project has its own compute charge, and any disk or egress beyond the included allowance bills per GB. Three modest overages routinely triple the invoice.
Does Supabase charge per project or per organisation?
Both, in different places. The plan fee is charged per organisation. Compute is charged per project. This split is the single biggest source of unexpected invoices, because adding a project does not change your plan but does add a recurring compute line.
Is Supabase cheaper than running your own Postgres?
At one small project, usually yes, because the included compute credit covers it. As you add projects with steady traffic, the arithmetic reverses: you are paying a per-project compute premium for instances that never scale to zero. That is the point where a flat, provisioned plan tends to win.
How do I forecast a Supabase bill before I commit?
Estimate in this order: number of projects times compute tier, then egress in GB, then database size in GB. Compute dominates for most teams, egress dominates for media-heavy apps, and storage only matters once you cross 8 GB per project.