Read Your Supabase Bill：計算、用量、支出上限涵蓋與不涵蓋項目，以及簡易成本模擬器

I wanted to know one thing before my first real Supabase invoice: if usage jumps, what does the bill do, and does the spend cap really keep it safe? I read the Billing and Usage pages of a Pro organization, the docs, and built a simulator that shows the bill with the cap on and off. All from my run on 2026-10-27. Prices change, so every number is dated.

How this was made: I wrote this with Claude's help: it drafted, and I ran every step, edited the text, and checked the results. The mistakes are mine. This is a personal learning project, not an official guide, and I don't work for Supabase.

The non-technical version (three boxes, and why "stop" and "bigger bill" are different): https://medium.com/p/fd38d7d84bb2
The code: https://github.com/tomozilla/cost-simulator-en-demo

What I did and did not do

I changed no billing setting. I did not toggle the spend cap, add an add-on or change a plan. I opened the cap dialog and cancelled it.
I did not trigger the cap. What the service actually does at the quota (which things stop, in what order) is from the docs, not from my run.
The only number I could check against my own invoice: Micro compute for 478 hours = $6.42. The rest comes from the pricing page and docs as of 2026-10-27 (USD, no tax).
Cost of this walkthrough: $0.
On the Pro screenshots I replaced the project name with my-project and left out the plan-fee line.

A bill is three boxes

Base fee: the plan price. Per the docs it is charged upfront each cycle.
Compute: each project's database machine, counted by the hour and charged in arrears.
Usage: users, traffic, storage and similar, only the part over the included amount.

Reading the Upcoming Invoice

The Billing page of an organization has an "Upcoming Invoice" for the current cycle. Here is the compute part:

478 hours, $6.42. Micro is $0.01344 per hour, and 478 x 0.01344 = $6.42, so the screen and the pricing page agree. The next line, Compute Credits -$6.42, is the $10 of compute that paid plans include (pricing page and docs), which covers one Micro.

The docs add that compute is only counted while a project is active: paused projects are not charged.

Reading the Usage page

Every item has an allowance: egress 250 GB, 100,000 monthly active users, 100 GB of storage, 5 million Realtime messages, 2 million Edge Function invocations. Compute hours are on the same page.

The page says it can take up to an hour to refresh, so this is not a live meter. I would open it on a fixed day each month. Without a habit, you won't see the slope.

The spend cap

Billing has a Cost Control section:

ON: for the items the cap covers (disk, egress, storage and so on; see below), going past the allowance adds no overage charge, but the project can become unresponsive (API requests get a 402) or read-only. Items the cap does not cover (compute, PITR, custom domains) are billed even with the cap ON.
OFF: it keeps running and the extra usage is billed.
Per the pricing page and docs, it is a Pro feature and on by default. On Free you are never charged.

So the cap trades a bigger bill for a stop. I opened "Change spend cap" and cancelled:

The table lists the per-unit price beyond the allowance (for example egress: 250 GB included, then $0.09 per GB). Turning the cap off means those prices apply.

What the cap covers, and what it doesn't

The docs page "Control your costs" lists both.

Covered (past the quota, use is refused instead of billed): disk size, egress, Edge Function invocations, logs ingest and query, monthly active users (including SSO and third-party), Realtime messages and peak connections, image transformations, storage size.

Not covered (charged either way): compute (also branching and read replica compute), custom domains, extra disk IOPS and throughput, IPv4, log drains, phone MFA, and point-in-time recovery (PITR). The docs' reason: those are predictable and chosen by you.

One more line from the docs matters: the cap can't set per-item budgets or send a notification when costs reach a level. "Tell me when I'm at 80%" is not something it does. You have to check the Usage page.

Three ways bills balloon

A sudden rush of traffic or users. With the cap on, the bill stays flat and service is limited. With it off, the bill grows.
A bigger machine. Compute is not covered by the cap. Per the docs, if you upsize for 10 hours and go back, you pay the larger size for those 10 hours.
An add-on. PITR ($100 per month per 7 days of retention) and a custom domain ($10 per month) are outside the cap.

Update (2026-10-27): after reading the docs again: a project that uses PITR needs at least the Small compute add-on (Micro is $10, Small is $15, so about $5 more a month), and turning PITR on stops the daily backups. I cover this in the backup article of this series. The $100 above does not include these.

The cost simulator

Words only go so far, so I built a page: enter a month of usage, see the bill with the cap ON and OFF.

It is static: no server, no project, no keys. Rates live in a dated rates.json.

The logic splits items into two groups. Uncapped items (compute, PITR, domains) are the same either way. For capped items, past the allowance the cap-ON column says "refused", and the cap-OFF column adds over x rate:

const over = Math.max(0, used - included);   // past the allowance
// cap ON : the bill doesn't grow, the item is refused
// cap OFF: add  over x rate  to the bill

cd app && python3 -m http.server 8000   # open http://localhost:8000/
node test.js                            # 17 checks

Case 1: traffic x10

I used the "traffic x10" button, then set egress to 600 GB and users to 150,000:

Hand check for OFF: $25 + 350 GB x $0.09 ($31.50) + 50,000 users x $0.00325 ($162.50) = $219. The screen agrees.

The $25 under cap ON is the price of being refused, not a sign that everything is fine. The page says so in the row ("refused past quota").

Case 2: the cap that doesn't help

Three projects on Medium, one PITR, one custom domain:

$305 either way: $25 + $180 (3 x Medium) - $10 included + $100 PITR + $10 domain. No cap setting changes this.

Stumbles

The x10 button compounded

My first version multiplied the current values on every click. Two clicks gave x100 (egress 50 -> 500 -> 5,000 GB) and the page said nothing. Now the button toggles: the first click remembers the normal values and multiplies by 10, the second restores them (the label becomes "Back to normal").

Silent fixes of bad input

Blank, negative or non-numeric values became 0, and "0 projects" became 1, without a word. Now the fixes are listed above the result:

My first fix still missed one case: "0 projects" counted as a valid number, so it never appeared in the list. I fixed that too.

Limits

The simulator cannot show what the service actually does at the quota.
Team: the docs say the spend cap is "available only with the Pro Plan", and the usage pages say that on Team "you will pay for any overages". So for Team the page shows one total and a note instead of the ON/OFF pair. That comes from the docs (read 2026-10-27); I have not run a Team organization.
Not tested: tax, currency, phone-width layout, opening the page as a file.

What it costs

This walkthrough and the simulator: $0.
A month is roughly plan fee + compute (hours x rate, minus the $10 included) + usage over the allowance (when the cap is off) + add-ons.
Per the docs, if an invoice goes unpaid, your projects are paused and the organization is downgraded to Free.
Verified against my invoice: only the 478 hours = $6.42 line. Everything else is from the pricing page and docs.

If I took this further

Not tried: pasting real usage into the simulator instead of typing it, writing down the team's "stop or bigger bill?" decision next to the cap setting, and a calendar reminder for the monthly usage check.

Takeaways

Cap ON is a stop, not a free pass. "Won't grow" and "won't stop" differ.
Compute, PITR and custom domains are not covered. Price them before you add them.
The cap has no alerts. Check the Usage page on a schedule.
In a number tool, don't compound a button and don't fix input silently.

Next in this series: backups and point-in-time recovery.