Stopping Surprise Overage Bills on Supabase — Setting Up Spend Cap to Hand Databases to Vibe Coders Safely
“Vibe coding” has gone mainstream, and we are now in an era where people who barely write code can stand up an app on a BaaS like Supabase. Handing a Supabase database directly to non-developers, whether colleagues inside the company or for client prototyping, is an increasingly common scenario.
The first obstacle is the fear of billing. Supabase uses a hybrid pricing model: each plan has a free allowance (quota), and going over it triggers usage-based charges. Non-developers generally do not know what “Egress” or “MAU” mean, let alone how they map onto a bill. If the person you handed the database to pushes a lot of data, or runs code with an infinite reconnection loop, an unexpectedly large invoice at month’s end is entirely plausible.
So the question becomes a single point: does Supabase have a setting that does not charge for usage over the free allowance? This post investigates that against the Supabase docs and pricing page as of June 2026, and works through to a safe configuration for handing out databases. Pricing and policy move fast, so always check the official pages as of your own date before adopting anything in production.
The Conclusion — Only Free and Pro (Spend Cap On) Stay Flat
Here is the conclusion up front. Overage behavior splits into two cases depending on plan and setting.
- Flat rate (no charge for overages): Free plan, and Pro plan + Spend Cap on (the default). Exceeding quota triggers a service-side restriction rather than a charge.
- Usage-based (overages billed by the GB and so on): Pro plan + Spend Cap off, Team plan, Enterprise plan. The service keeps running and overages are added to the invoice.
So the answer to “I want to stop surprise overage bills” is to use the Free plan, or to keep Spend Cap on under the Pro plan. Spend Cap is on by default on Pro, so unless you deliberately turn it off, Pro stays flat too. Note that the Team plan and above have no concept of Spend Cap at all, so overages there are always billed.
Every “Manage your usage” page in the docs spells out the boundary the same way: “If you are on a paid plan and have Spend Cap disabled, or your organization is on the Team Plan or above, you will pay for any overages.” Conversely, in every other case (Free, and Pro + Spend Cap on) no overage charge occurs.
Billing Runs at the Organization Level
Before the mechanics, fix the unit of billing. Supabase bills per “organization,” not per “project.” Each organization holds a single plan (Free / Pro / Team / Enterprise), and the free allowance applies to the whole organization. If an organization holds multiple projects, their usage is summed and compared against the quota.
So when you hand a database to a non-developer, the question of whose project belongs to which organization is itself the boundary of your billing risk. If you want to isolate risk, the basic move is to separate organizations by person and by purpose. As covered below, splitting development/testing organizations from user-facing ones, each with its own plan and Spend Cap setting, is the safe design.
How Spend Cap Works — A Pro-Only Binary Toggle
Spend Cap is a toggle that decides whether an organization is allowed to exceed its plan quota. The docs state plainly that “this feature is available only with the Pro Plan”; it does not exist on Team or Enterprise.
With Spend Cap on (flat rate), once you exceed quota the additional use of that item is blocked until the next billing cycle, and no overage charge occurs. Your cost is pinned to the base fee ($25/mo on Pro) plus compute.
With Spend Cap off (usage-based), the project keeps running and overages are billed at the rates on the pricing page. It scales seamlessly through a traffic spike, but your invoice grows accordingly.
Two important constraints live here. First, Spend Cap is not a dollar-amount cap. The docs state that Spend Cap “does not allow for fine-grained cost control,” and it offers no way to set a budget like “up to $100/month” or to get a notification when a certain dollar figure is reached. All it offers is the binary of full block or full usage-based. This is a long-standing limitation that users have requested be addressed for years.
Second, Spend Cap is unavailable for organizations managed via AWS Marketplace (always usage-based). If you want cost fully pinned, create the organization through a direct Supabase contract rather than via AWS Marketplace.
What Spend Cap Does and Does Not Cover
The single most important fact when handing out a database is that even with Spend Cap on, some items are not protected (always billed). Assume “Spend Cap is on, so I can never be charged” without grasping this, and you walk straight into an unexpected invoice.
Items that are blocked with Spend Cap on (and so stay within the flat rate):
- Disk size (database capacity)
- Egress (unified data transfer)
- Edge Function invocations
- Log ingestion and queries
- MAU (monthly active users, including normal, SSO, and third-party)
- Realtime message count and peak concurrent connections
- Storage image transformations
- Storage size (file capacity)
Items that are always billed even with Spend Cap on (not protected):
- Compute, branching compute, read replica compute
- PITR (Point-in-Time Recovery)
- Custom domains, IPv4 addresses
- Additionally provisioned disk IOPS and throughput
- Log Drains, Advanced MFA Phone
These sit outside Spend Cap because they are “predictable items the user explicitly opts into.” Flip that around: if a non-developer accidentally enables PITR or extra compute from the dashboard, a charge runs even with Spend Cap on. To hand out databases safely, the premise must be that such add-ons cannot be enabled (or that permissions are scoped down).
It is also worth remembering that in real operation, compute is often the largest cost driver, more so than egress or storage. Pro and Team include $10/month of compute credits (one Micro instance), but additional projects or larger instances pile up fixed costs independent of Spend Cap.
What Happens When You Exceed Quota
The post-overage flow differs entirely between the flat side (Free, or Pro + Spend Cap on) and the usage-based side (Pro + Spend Cap off / Team / Enterprise). As a diagram:
flowchart TD
A[Usage exceeds quota] --> B{Plan / Spend Cap}
B -->|Free or Pro + Spend Cap on| C[Notification to billing email]
C --> D[Grace period]
D --> E{Corrected?}
E -->|Yes| F[Back to normal operation]
E -->|No| G[Restrictions under Fair Use Policy]
G --> H[402 / read-only / pause / new-project block, etc.]
B -->|Pro + Spend Cap off / Team / Enterprise| I[Service continues]
I --> J[Overage billed by usage]
J --> K[Invoiced at next billing cycle reset]
L["Add-ons outside Spend Cap (PITR, Compute, etc.)"] --> K
On the flat side, exceeding quota first sends a notification to the billing email address and grants a grace period. Bring usage back under quota or upgrade within that window and you return to normal operation; leave it uncorrected and restrictions under the Fair Use Policy apply in stages. Those restrictions include project suspension, switching the database to read-only, disabling new project creation and transfers, and returning a 402 status on all API requests.
There is an operational trap here. The grace period is effectively one-time: once you have used it up, the next time you exceed quota you are restricted immediately with no grace. Also, once a restriction kicks in from exceeding quota, the rule is that it is not lifted until the next billing cycle even if you bring usage back down, and community reports note it can take up to about 24 hours after the cycle to reflect, sometimes requiring support intervention. “Flat rate” does not mean “unlimited use”; it means “stops when you exceed.” You should tell whoever you hand the database to about this up front.
On the usage-based side, instead of notification and restriction, overages are simply billed. The charge is not finalized the instant you use it; it settles as a postpaid item when the organization’s billing cycle resets. You get an email when you come within 20% of any plan limit, so if you allow usage-based billing, regularly checking that notification, the Usage page, and the Upcoming Invoice is the baseline.
Database Read-Only Mode Is a Separate Concern
Apart from billing, database capacity alone tends to behave as “does writing stop?” rather than “am I charged?” This can happen on both the flat and usage-based sides.
On the Free plan, the database enters read-only mode once the database size (the actual Postgres data) exceeds 500 MB. The key point is that this is judged on actual data size, not disk size (1 GB on Free). In read-only mode, writes like INSERT fail with cannot execute INSERT in a read-only transaction. Recovery is automatic once usage drops below 95% of the disk size. The official Understanding Database and Disk Size page has the details.
On Pro and above, the disk auto-expands by 50% once it reaches 90% of the allocated capacity (for example, 8 GB to 12 GB). But this auto-resize is capped at up to 4 times within a rolling 24-hour window, due to an AWS EBS constraint. If a large import hits the expansion limit within 24 hours and you still cross 95%, it cannot expand further and locks into read-only. So even on Pro, “being billed” does not mean “unlimited writes”; a sudden influx can halt writes. If you plan a large initial data migration, the safe move is to manually provision enough disk size in advance.
Key Overage Rates (as of June 2026)
In case you do allow usage-based billing, here are the main overage rates. All are in USD and apply to usage beyond the Pro/Team plan’s included allowance.
| Item | Included (Pro/Team) | Overage rate |
|---|---|---|
| Database disk size (gp3) | 8 GB | $0.125/GB/mo |
| Database disk size (io2) | 0 GB (billed from first byte) | $0.195/GB/mo |
| Egress (uncached) | 250 GB | $0.09/GB |
| Cached egress | 250 GB | $0.03/GB |
| File storage size | 100 GB | $0.0213/GB/mo |
| MAU (monthly active users) | 100,000 | $0.00325/MAU |
| Edge Function invocations | 2M | $2 per 1M |
| Realtime messages | 5M | $2.50 per 1M |
| Realtime peak connections | 500 | $10 per 1,000 |
| Image transformations | 100 | $5 per 1,000 |
Egress is handled as a single Unified Egress Quota that sums outbound traffic across all services: Database, Auth, Storage, Edge Functions, Realtime, Log Drains, and Supavisor. Media apps that serve a lot of images or video, and chat apps that lean heavily on realtime sync, are structurally at high risk of burning through 250 GB without the developer realizing it. For an app built by a non-developer, assume egress and MAU are the items most likely to produce a surprise charge.
A Safe Configuration for Handing Databases to Vibe Coders
With all of the above, here is the recommended configuration for handing a Supabase database to a non-developer. The aim is to structurally prevent surprise overage billing.
As the foundation, pin the organization you hand over to the Free plan, or to the Pro plan with Spend Cap on. That is the core of guaranteeing a flat rate. For testing or prototypes, Free is often enough and reduces billing risk to zero. Move to Pro once you need compute, daily backups, or a custom SMTP in production, but keep Spend Cap on even then.
Next, make sure the items outside Spend Cap’s protection (PITR, extra compute, custom domains, IPv4, and so on) cannot be enabled by the other party on a whim. Hold this down operationally: scope dashboard permissions, keep the organization owner role to yourself, and do not let the person touch billing settings. This is the single thing to watch most closely, because a charge runs here even with Spend Cap on.
Then separate organizations by person and by purpose. Because billing is per organization, splitting them means one person’s runaway usage does not spill onto others. Even if a Free organization exceeds quota, no charge occurs and it merely stops via read-only or suspension, so the damage is confined to a service outage within that organization.
Finally, share the trade-off with the other party: choosing flat means the service stops when you exceed quota. Usage-based (Spend Cap off) is sometimes recommended for production where availability is paramount, but on the premise of handing a database to a non-developer, “stopping is safer than uncapped billing” is the correct call in nearly every case.
Wrap-Up
The key points:
- A setting that does not bill overages does exist on Supabase. Use the Free plan, or keep Spend Cap on under Pro, and your cost is pinned to a flat rate.
- Spend Cap is a Pro-only toggle, on by default. It does not exist on Team and above, where overages are always billed.
- Spend Cap is not a dollar-amount budget cap; it is the binary of full block or full usage-based. You cannot set “up to X per month.”
- Even with Spend Cap on, add-ons like PITR, extra compute, custom domains, and IPv4 are always billed. With non-developers, an operating model that prevents them from enabling these is essential.
- On the flat side, exceeding quota triggers restriction, not a charge (notification → grace period → suspension/read-only under Fair Use Policy). The grace period is effectively one-time.
- Database capacity is a separate axis: Free goes read-only over 500 MB, and Pro can go read-only on hitting the disk-expansion limit.
- To hand out safely, separate organizations per person, pin to Free or Pro + Spend Cap on, and do not let anyone touch the unprotected add-ons.
A setting to stop surprise overage bills genuinely exists. But the key to handing a database to a non-developer with peace of mind is to use it with an understanding of the unprotected add-ons and of the fact that the service stops when you exceed quota, rather than assuming “Spend Cap on means free no matter what.”
That is a look at Supabase’s overage-stopping settings through the lens of handing databases to vibe coders safely, reported from the field.