$0.00325. That is the exact price of one extra monthly active user on Supabase's Pro plan, once you cross the 100,000 included in the $25 base fee, according to Supabase's own pricing page. It is such a small number that most Supabase pricing breakdowns treat it as a footnote and move on to the next line item.
That number is also almost beside the point. The default setting on every paid Supabase project does not let that $0.00325 charge happen at all. It blocks the 100,001st signup instead, silently, with no email and no dashboard banner, and most comparisons of Supabase pricing never get to that part.
What the $25 a month actually buys
Supabase runs four tiers: Free, Pro, Team, and Enterprise. Supabase's pricing page lists the Free plan at $0 with a 500 MB database, 1 GB of file storage, 5 GB of egress, and 50,000 monthly active users, capped at two active projects that pause after a week of inactivity.
Pro starts at $25 a month per project. It raises every one of those ceilings: an 8 GB database, 100 GB of file storage, 250 GB of egress, and 100,000 monthly active users, and it stops the inactivity pause entirely. Team starts at $599 a month per organization and adds compliance features like SOC 2 and ISO 27001 support on top of the same usage quotas as Pro. Enterprise pricing is custom and negotiated directly with Supabase's sales team.
Every one of those included amounts has a published overage rate once you exceed it: $0.125 per extra GB of database, $0.0213 per extra GB of storage, $0.09 per extra GB of egress, and the $0.00325 per extra monthly active user mentioned above. On paper, that reads like a normal usage-based pricing model. The part that changes the story is what decides whether those overage rates ever actually get charged.
The compute add-on is a second, separate bill
The $25 plan fee does not include the compute instance that runs your Postgres database. That is billed as its own line item, starting at the Micro tier.
Supabase's pricing page lists ten compute sizes: Micro at $10 a month with 1 GB of RAM, up through 16XL at $3,730 a month with 256 GB of RAM. Pro and Team plans both include a $10 monthly compute credit, which is subtracted from whichever tier you run, so Micro effectively costs nothing extra and moving up to Small only costs the $5 difference between its $15 price and the credit.
That math is worth doing before picking a tier, because the jump from Small to Medium is a $45 difference once the credit is applied, not the full $60 sticker price, and the gap keeps compounding at every size above it. A project that outgrows Micro during a traffic spike and gets bumped to Medium is looking at roughly $50 a month in added compute cost, on top of whatever the plan fee and usage overages already add up to.
The default spend cap doesn't send a bigger bill. It sends silence.
Here is the part most Supabase pricing comparisons list as a feature and leave there: every paid plan ships with something called the spend cap, and it is on by default.
Supabase's own documentation on the spend cap describes exactly what happens when a project crosses a usage quota while the cap is on: "further usage of that item is disallowed until the next billing cycle." The cap does not pause the whole project. It restricts only the specific billable item that went over, which means a database can keep running completely normally while one particular function silently stops working.
In practice, that means hitting the monthly active user quota blocks new signups, specifically, while existing users keep working. Hitting the storage quota blocks new file uploads while reads keep working. Hitting the egress quota blocks additional data transfer out of the project. None of those failures throws an error that says "billing limit reached." They look exactly like a bug in your own signup flow, your own upload handler, or your own API, because from the application's point of view, that is exactly what they look like.
What turning the spend cap off actually trades away
The other setting is to turn the spend cap off. Supabase's documentation states that with the cap disabled, the project keeps running past every quota and "any additional usage will be charged based on the item's cost per unit, as outlined on the pricing page." New signups keep working. File uploads keep working. The bill keeps growing, at the same per-unit rates listed above, for as long as nobody is watching the usage page.
That is not a worse setting than the default. It is a different failure mode. With the cap on, growth past a quota breaks a feature quietly. With the cap off, growth past a quota grows the invoice quietly. Supabase's own recommendation, per the same cost control page, is to monitor the usage dashboard manually once the cap is off, since the platform will not flag the cost increase for you either way.
As an illustration of how fast that second scenario compounds: a Pro project that grows from 100,000 to 150,000 monthly active users with the spend cap off adds 50,000 users at $0.00325 each, or roughly $163 a month, on top of the $25 base fee and whatever compute tier it needs to handle the extra load. That is a manageable number for a team watching for it and an invisible one for a team that is not, since nothing on the account prompts anyone to go check.
Where this actually gets caught
Neither setting fixes the underlying gap: Supabase's billing system reacts to usage, it does not warn anyone ahead of it. Catching a quota before it blocks a signup flow, or before an overage bill compounds for a full billing cycle, means building that monitoring yourself, on a schedule, against Supabase's own usage data.
That is a small, specific automation, not a platform feature: a scheduled check against Supabase's usage API, with a Slack or email alert fired when monthly active users or egress crosses some threshold like 80 percent of the plan's included quota. It is exactly the kind of scheduled, API-triggered build our workflow automation team sets up for clients running on usage-based infrastructure, so a quota gets flagged days before it blocks a feature, not discovered after a support ticket comes in asking why new users can't sign up.
The other half of the gap is visibility once that data exists. A Slack alert says a quota got close. It does not show the trend that got a project there, whether MAU growth is seasonal, steady, or about to double again next month. That trend line is what our analytics team builds into a client's reporting, because a growing app that already knows its MAU curve six months out can budget for the next compute tier or plan upgrade before a spend cap ever gets the chance to block anything.
The rule worth remembering
Supabase's plan pricing is honestly simple: $25 a month buys real, generous quotas, and the published overage rates are small enough that genuine usage-based billing rarely hurts anyone. The part that bites is not a rate. It is the default assumption that "no bigger bill" means "no problem," when the actual tradeoff is a silent feature outage with no built-in alert attached to it.
Check which setting your Supabase projects are running on before traffic forces the question. If the spend cap is on, know exactly which feature breaks first when a quota hits. If it's off, put a monitor on usage yourself, because Supabase's own documentation confirms it will not put one there for you.
