Supabase pricing in 2026: plans, compute, the spend cap, and what you’ll actually pay

How much does Supabase cost?

Supabase charges a plan fee per organization, compute per project per hour, and usage beyond each plan’s quotas. Prices from Supabase’s pricing page on October 13, 2026:

The Free plan is for trying things, not for production. It has no automatic backups, allows two active projects, and pauses projects after a week of low activity. A launched product belongs on Pro.

How is Supabase compute billed?

Compute is the line most people misread. Every project runs on its own compute instance, billed per hour, and a part hour counts as a full hour. Paid plans include $10 of compute credits a month, which is exactly one Micro instance; the credits don’t roll over and don’t cover read replicas or branches.

So a Pro organization with one project on Micro pays $25: the plan, plus $10 of compute, minus $10 of credits. A second project adds at least $10, because on paid plans even the smallest size is billed as Micro. A staging project and a production project on Pro is therefore $35 before any usage.

Choose compute by connections and memory, not by plan. A serverless app that opens a connection per request runs out of direct connections long before it runs out of CPU, so connect through the pooler, which allows several times as many clients at every size.

What does Supabase charge beyond the included usage?

Overage prices on Pro and Team, from each item’s page in Supabase’s usage documentation:

Two details change real bills. Disk is charged on the size provisioned, not the data stored, and it only grows: Supabase expands it by 50% when the database reaches 90%, at most once every four hours, and it can’t be shrunk. And point-in-time recovery requires at least the Small compute size, so turning it on for a Micro project also adds $5 of compute.

What will you actually pay?

Three illustrations at list prices, assuming a month of steady use:

The consumer app shows where Supabase bills grow. Compute and storage stay small; sign-ins don’t. Every monthly active user past 100,000 costs $0.00325, so 200,000 more users add $650 a month. A business app with a few thousand users never sees that line, and its bill is mostly compute and backups.

You can model your own bill in a few lines. This estimator follows the Pro plan’s rules: compute per project minus the $10 credit, and each usage line only above its quota:

const PRO = { plan: 25, computeCredit: 10, mau: 100_000, egressGb: 250, cachedEgressGb: 250, storageGb: 100, diskGbPerProject: 8 };
const RATE = { mau: 0.00325, egressGb: 0.09, cachedEgressGb: 0.03, storageGb: 0.0213, diskGb: 0.125 };
const COMPUTE = { micro: 10, small: 15, medium: 60, large: 110, xl: 210, '2xl': 410 } as const;

type Usage = {
  projects: { compute: keyof typeof COMPUTE; provisionedDiskGb: number }[];
  mau: number;
  egressGb: number;
  cachedEgressGb: number;
  storageGb: number;
};

const over = (used: number, included: number) => Math.max(0, used - included);

export function estimateProBill(u: Usage) {
  const compute = u.projects.reduce((sum, p) => sum + COMPUTE[p.compute], 0);
  const lines = {
    plan: PRO.plan,
    compute: Math.max(0, compute - PRO.computeCredit),
    disk: u.projects.reduce((sum, p) => sum + over(p.provisionedDiskGb, PRO.diskGbPerProject) * RATE.diskGb, 0),
    mau: over(u.mau, PRO.mau) * RATE.mau,
    egress: over(u.egressGb, PRO.egressGb) * RATE.egressGb,
    cachedEgress: over(u.cachedEgressGb, PRO.cachedEgressGb) * RATE.cachedEgressGb,
    storage: over(u.storageGb, PRO.storageGb) * RATE.storageGb,
  };
  return { ...lines, total: Object.values(lines).reduce((a, b) => a + b, 0) };
}

// The consumer app above: about $707
estimateProBill({
  projects: [{ compute: 'small', provisionedDiskGb: 24 }, { compute: 'micro', provisionedDiskGb: 8 }],
  mau: 300_000, egressGb: 400, cachedEgressGb: 200, storageGb: 150,
});

Add the fixed extras you choose, such as point-in-time recovery, a custom domain or IPv4, on top.

What does the Supabase spend cap do?

The spend cap is a Pro-plan setting, on by default, that stops usage-based charges instead of billing them. With it on, once an item reaches its quota, further usage of that item is disallowed until the next billing cycle, and your project is restricted under Supabase’s fair use policy, which can mean read-only databases or requests refused with a 402 status.

It covers usage you don’t control: disk size, egress, monthly active users, Edge Function invocations, Realtime, image transformations and file storage. It doesn’t cover what you opted into: compute, read replicas, branches, point-in-time recovery, custom domains, IPv4 and log drains are always billed.

That makes it a trade-off, not a safety net. With the cap on, a launch that goes better than expected can take your app read-only partway through the month; and because disk can’t auto-scale past 8 GB with the cap on, a growing database hits the same wall. A reasonable rule: keep the cap on while you build, and turn it off at launch, alongside your own usage alerts. Supabase itself notes that the cap doesn’t offer budgets or notifications, so the alerts are yours to add. On Team and above there is no cap; overages are billed.

How do you see what’s driving your Supabase bill?

The usage page shows each line against its quota, and the upcoming invoice updates as you go. For disk, the database will tell you where the space went:

-- How big is the database, and which tables are the bulk of it?
select pg_size_pretty(pg_database_size(current_database())) as database_size;

select relname as table_name,
       pg_size_pretty(pg_total_relation_size(relid)) as total_size,
       pg_size_pretty(pg_indexes_size(relid)) as index_size
from pg_catalog.pg_statio_user_tables
order by pg_total_relation_size(relid) desc
limit 10;

-- How close are you to your compute size's connection limit?
select count(*) as connections, max_conn.setting::int as max_connections
from pg_stat_activity, (select setting from pg_settings where name = 'max_connections') max_conn
group by max_conn.setting;

The usual savings, most of them from Supabase’s own guidance:

• Select fewer columns and rows. Uncached egress is $0.09 a GB, and select * on a wide table is the most common reason it grows.
• Cache what you serve. Files through the CDN count as cached egress at a third of the price.
• Delete what nobody uses: idle projects, preview branches and old logs. Each project costs at least $10 a month on a paid plan.
• Start small on compute and move up when connections or memory, not habit, say so.
• Clean up before the disk grows. Since disk can’t shrink, archive old rows and drop unused indexes before a 90% trigger expands it for good.

Is Supabase cheaper than the alternatives?

For most products at launch, yes: $25 a month covers a database, authentication, storage, realtime and functions that would otherwise be several services. The comparison with Firebase, including where Firebase’s pay-as-you-go model wins, is in Supabase vs Firebase.

Whatever you run on, the expensive mistakes on Supabase are rarely the price list. They’re open tables, a secret key in the browser, or a missing backup; Supabase RLS not working? covers the first. We audit apps built on Supabase for exactly those, at a fixed price.

What next?

Open your project’s usage page and note three numbers: monthly active users, egress and provisioned disk. Put them into the estimator above with your compute sizes, and you’ll know next month’s bill before Supabase does. If the number surprises you, or you’re about to launch on the Free plan, send us the project details.