Supabase Pricing 2026: What $25 Really Gets You

Supabase pricing runs from $0 to $599 a month before you touch a single usage meter, but neither of those numbers is the one that decides your bill. The number that matters is $25, and what it covers is widely misreported. Pro is billed per organization, not per project, and almost every guide currently ranking for this term gets that wrong.

Supabase is the Postgres development platform that bundles a database, Auth, Storage, Edge Functions, and Realtime behind one subscription, which is why a per-gigabyte comparison against a plain database provider tells you very little. We run a fixed-instance Postgres host, so we have modelled this bill more times than we can count, and the maths here cuts both ways. Most of the corrections below make Supabase look cheaper than the internet currently thinks it is.

Every figure was verified against supabase.com on August 5, 2026. By the end of this you will know what your workload costs and which meter moves first.

Key takeaways

• Pro is $25 per organization, not per project. Additional projects start at $10 a month.
• The $10 compute credit applies once per organization. Production plus staging on Micro is $35 a month, not $50.
• Free bandwidth is 10 GB, not 5 GB. 5 GB egress plus 5 GB cached egress. Pro is 500 GB, not 250.
• Cached egress is $0.03 per GB against $0.09 uncached, so a good cache ratio cuts bandwidth cost by roughly two thirds.
• There are two storage meters, about six times apart. Database disk at $0.125 per GB, file storage at $0.0213 per GB.
• Team at $599 buys governance, not capacity. Pro and Team carry identical usage quotas.

How Supabase pricing works in 2026

Supabase bills per organization, not per project. One subscription covers every project inside that organization, usage quotas are pooled across all of them, and compute is charged separately for each project with no quota at all.

That single asymmetry explains most of the confusion about Supabase pricing.

The pooling cuts in your favour. Egress, file storage, and monthly active users are measured across the whole organization, so a second project draws on the same allowance rather than getting its own. Supabase’s billing documentation is explicit: the quota “is applied to your entire organization, independent of how many projects you launch.”

Compute works the opposite way. Every project runs on its own dedicated Postgres instance, and you pay for that instance whether the database is busy or idle. In Supabase’s words, “each project you launch increases your monthly Compute costs.” Add a staging environment and you are not buying a second subscription, you are buying a second instance.

One constraint follows from the same model: plans cannot be mixed inside an organization. You cannot keep one project on Free and another on Pro in the same org. Running both means running two organizations.

This is where several widely cited pricing guides go wrong, including one currently ranking on page one, by describing Pro as “$25 per project.” It is $25 per organization.

The distinction changes the maths for anyone running more than one environment, which is most teams past their first deploy. For context, $25 is at the low end of what managed Postgres costs across providers, and it buys a good deal more than a database.

Plan prices and quotas verified against supabase.com on August 5, 2026.

Working out the predictable version of this bill?
Selfhost.dev prices Postgres as a compute instance you choose, plus metered storage and egress, drawn from a prepaid credit balance so there is no invoice you did not see coming. You can price the same workload on fixed-instance pricing without creating an account.

Is Supabase free? Free tier limits, verified August 2026

Yes. Supabase’s free plan costs $0 per month with no time limit and no expiry, which makes it a genuine free tier rather than a trial. Three limits decide whether you can ship on it: 500 MB of database storage, 10 GB of bandwidth, and automatic pausing after one week without traffic.

Supabase free tier limits (verified August 2026)

Two of those numbers are routinely misreported, and both matter.

Bandwidth is 10 GB, not 5 GB. Every guide currently ranking for Supabase pricing quotes 5 GB. The pricing page lists two separate lines, 5 GB egress and 5 GB cached egress. Supabase’s bandwidth documentation adds them explicitly: free organizations have “a limit of 10 GB of bandwidth (5 GB cached + 5 GB uncached).” If you have been budgeting against 5 GB, you have twice the headroom you thought.

The 500 MB is your data, not your disk. A free project goes read-only when database size exceeds 500 MB, and the docs are explicit that “this is the database size limit (the size of your actual Postgres data), not the disk size.” Free projects get 1 GB of disk, so the write-ahead log and system files do not eat your quota.

The two-project limit follows you, not the organization. Supabase’s docs are specific: it “applies across all organizations where you are an Owner or Administrator,” so creating extra organizations does not multiply your free allowance. Paused projects do not count against it.

What happens when a free project pauses

After seven days without traffic, a free project pauses and has to be restored manually from the dashboard. That is acceptable for a demo and disqualifying for anything a customer might load on day eight, which is the single most common reason teams move to Pro, ahead of any resource limit.

The other exit is self-hosting, since Supabase is open source and you can run Supabase on your own infrastructure with no plan fee at all. That trade is real in both directions. We put a number on that second half: what self-hosting Supabase costs to own, from the server the seventeen containers need to the upgrade that lands every few months.

Pausing is not a Supabase quirk. It is the house style of free Postgres: Neon suspends compute until the next billing month, Render deletes the database 30 days after you create it, and Aiven powers off until a human restarts it. We read all six free tiers against their own docs, and not one of them fails by charging you.

Supabase Pro pricing: what $25 actually covers

Supabase Pro is $25 per month per organization, and it includes $10 in monthly compute credits, which is exactly the cost of one Micro instance. That is why so many production apps sit at precisely $25, and why the second project costs $10 rather than another $25.

Pro also ends the behaviour that pushes most teams off Free: projects never pause. It adds daily backups with 7-day retention, email support, and 7-day log retention. Point-in-time recovery is not part of that. It is a paid add-on.

Instances are billed hourly and scale up to 16XL at $3,730. The price quadruples from Small to Medium, the steepest proportional jump on the ladder, and dedicated CPU begins at Large.

The credit is applied once per organization, at the invoice, not once per project.

Supabase’s own cost estimator makes the arithmetic explicit: one Micro project is $25 subscription plus $10 compute minus the $10 credit, so $25. Add a second Micro project and you get $35, which matches the line on their pricing page: “First project included. Additional projects from $10/mo.”

So production and staging on Pro costs $35 a month, not $50.

What Supabase actually costs: three real workloads

A side project on Free is $0. An early production app on Pro is exactly $25. A growing app on Medium compute serving a terabyte a month lands near $150. Inputs are stated so you can reproduce each one.

The pattern holds across all three. In the growing-app column, compute and egress account for $117.50 of a $150 bill, while both storage meters together come to $7.38. Storage is almost never why a Supabase bill grows. Compute and egress are.

That pattern is not specific to Postgres. Price a ClickHouse Cloud Basic service at six, twelve, and twenty-four active hours a day and storage holds flat while compute quadruples, from $39.91 to $159.66, on a total that runs $66.52 to $186.27.

That egress figure assumes everything is served from origin. If a decent share is served from cache, which bills at a third of the rate, the $67.50 falls sharply.

If your own numbers sit between those columns, it is worth modelling a quiet month against a busy one before you pick a plan, because the variable lines are the ones that decide the bill.

This is also where the model diverges from metered competitors. The same workload on a provider that scales compute to zero can cost dramatically less if the traffic is bursty and dramatically more if it is steady, which is worth understanding before you treat $150 as expensive. How serverless Postgres bills the same workload works through that comparison.

Supabase storage and egress pricing

Supabase meters storage twice and bandwidth twice. Database disk costs $0.125 per GB per month beyond your allowance, file storage costs $0.0213 per GB, and egress beyond the included bandwidth is billed at $0.09 per GB uncached or $0.03 per GB cached. Confusing the first two is the most common costing mistake in this pricing model.

Supabase database storage pricing

Database storage is the expensive meter, at $0.125 per GB per month beyond the 8 GB included on each Pro project. It is charged per project rather than pooled, and the allowance covers your data, the write-ahead log, and system files together.

On paid plans the disk also grows itself, which matters more than the rate does. More on that below.

Supabase file storage pricing

File storage is the cheap meter, at $0.0213 per GB per month beyond the 100 GB included on Pro. The gap between the two is close to six times, and it runs in the direction most people do not expect. The database is the expensive place to keep bytes. The object store is cheap.

The $0.125 rate is often quoted as the answer for file storage, which overstates it by roughly 6x. If your storage line looks alarming, check which meter you are reading.

Supabase bills file storage on a monthly average rather than a live snapshot, so deleting large amounts of data late in the billing cycle has little immediate effect.

Supabase egress and bandwidth pricing

Bandwidth is split across two meters with separate allowances and separate rates. Free gets 5 GB of each. Pro gets 250 GB of each, for 500 GB of included bandwidth in total.

Cache hits are billed, which catches people out, but at a third of the uncached rate. A Supabase engineer confirmed the charge publicly, and the rate gap is the more useful half of the fact. Serving a gigabyte from cache costs $0.03 against $0.09 from origin, so a healthy cache ratio cuts your bandwidth bill by roughly two thirds rather than eliminating it.

Egress is the meter most likely to surprise a media-heavy app, because it scales with traffic rather than with what you store.

Auth, Edge Functions, Realtime and the paid add-ons

Supabase meters more than twenty line items beyond compute, storage, and egress. The bundled services are generous. The add-ons have no free allowance at all.

The Auth line is the one to notice. Fifty thousand monthly active users for free, and a hundred thousand on Pro, is more than most dedicated auth providers include at any price, and it is a genuine reason the bundle works out cheaper than assembling the same stack yourself.

Add-ons behave differently. They carry no included quota at all, so they charge from the first unit:

• Point-in-Time Recovery: $100 a month per 7 days of retention
• Custom domain: $10 per domain, per month, per project
• Log drains: $60 per drain per month, plus usage
• Read replicas, dedicated IPv4, branching, pipelines, and phone-based MFA: Priced per project on the same pay-as-you-go basis

Two of those catch people out. PITR is never a Pro inclusion, so if you assumed point-in-time recovery came with the $25, budget another $100. The $10 custom domain is why the community figure for one production app is usually quoted as $35 rather than $25.

One thing that is not a separate meter: pgvector runs inside your Postgres instance, so it consumes compute and disk rather than a dedicated vector-database line. For sizing, what pgvector costs to run in production covers the pattern in detail.

Where the Supabase bill surprises you, and how to avoid it

Most of what inflates a Supabase bill is already predictable: compute per project, two bandwidth meters, and paid add-ons that charge from the first unit. The surprises are elsewhere. Two behaviours catch teams out because they are easy to miss on the pricing page.

The first is that the spend cap is not universal. On Pro, spend caps are enabled by default, so services throttle or pause instead of generating overage charges, and spend-capped organizations receive a grace period under Supabase’s Fair Use Policy rather than an unexpected invoice. That protection disappears if you disable the spend cap or move to Team Plan or above, where overages are billed normally. The biggest bills are also the ones with the least protection.

The second is that database disks only grow automatically. Once a paid project’s disk reaches 90% utilisation, Supabase expands it automatically. It does not shrink it again during normal operation. According to the documentation, disks are only right-sized during a project upgrade, when they are reduced to 1.2× your database size. Supabase’s own example is a 200 GB disk holding 100 GB of data, which comes back to 120 GB after the upgrade. Until then, you’re paying for storage you no longer need, about $10 a month at the current database storage rate.

Neither behaviour is a hidden fee, but both can make a bill look surprising if you were only expecting to pay for what you actively use.

Four ways to keep your bill predictable:

• Leave the spend cap enabled while you’re on Pro.
• Put a CDN in front of file delivery and watch the cached bandwidth meter rather than assuming cache hits are free.
• Keep staging on the smallest compute tier that does the job.
• Check whether your allocated disk has outgrown your actual database size, since it will not shrink until a project upgrade.

This is also where most of the discussion on r/Supabase converges. The recurring complaint isn’t that Supabase is inherently expensive. It’s paying separately for production and staging environments, then discovering that avoiding those costs by self-hosting Supabase means taking on upgrades, backups, monitoring, connection pooling, and day-to-day operations yourself.

That is the gap Selfhost.dev is designed to fill. You still run a fixed-instance Postgres database, but you choose the instance size, storage and egress are metered separately, and everything is paid from a prepaid balance that pauses at zero instead of generating an unexpected invoice.

Paying for both production and staging?

Compare the same workload on fixed-instance Postgres and see exactly where the bill changes.

If the numbers work in your favour, try it yourself and run a Postgres instance alongside your existing Supabase project for a month before moving anything.

Supabase pricing vs the alternatives

Supabase is usually the cheapest option once you count what it bundles. A bare Postgres host plus a separate auth provider plus object storage with a CDN adds up past $25 faster than most cost comparisons admit. It stops being the cheapest when your workload is idle-heavy, egress-dominated, or already sitting inside AWS.

Every row in that table is a billing model rather than a price, which makes it the one comparison on this page with no number attached. For the numbers rather than the model, we costed nine Neon alternatives head to head, and on one 2 vCPU, 8 GB, 100 GB database they run from $79 to $195 a month.

On the AWS question, at small scale Supabase Pro is cheaper than assembling RDS, Cognito, S3, and a functions layer, mostly because you buy one bill instead of five. AWS becomes cheaper on raw compute with reserved instances, but only after you account for every charge on an RDS bill.

If Supabase isn’t the right fit, see the alternatives ranked by use case. If you’re deciding between Supabase and Selfhost.dev, compare them side by side on price and billing predictability.

The Bottom Line on Supabase Pricing

Supabase pricing is honest and unusually well documented. The problem is that almost nobody reads past the plan card, which is why so many of the numbers in circulation are wrong in the same direction. At $25 per organization, it is one of the better-value backend platforms you can buy. After that, your bill is driven far more by compute, bandwidth, and storage than by the subscription itself.

Stay on Supabase if you want Postgres, Auth, Storage, Realtime, and Edge Functions from one vendor, your traffic is predictable, and one production environment is enough. Start looking at fixed-instance Postgres when you’re paying for multiple environments, your workload is steady, or you need to know next month’s bill before it arrives.

If you’re in that second group, start by estimating the same workload on fixed-instance Postgres. Then compare it against your current Supabase bill, line by line. If the numbers stack up, run a Postgres instance alongside your existing Supabase project for a month before deciding whether to migrate.

Frequently Asked Questions