Supabase pricing: helping customers predict what happens next

Supabase gives a developer a clear starting price, then introduces several ways the bill can change. The product question is whether a customer understands those changes before making the decision that creates them.

My working hypothesis is that a forecast and an explicit control at the point of change could improve cost comprehension without hiding the underlying meters. Customer behavior, willingness to pay, and provider economics remain open questions that require internal evidence.

What the current pricing establishes

Pro starts at $25 per month and Team at $599. Paid plans include $10 in monthly compute credits, enough for one Micro instance. The pricing page says additional projects start at $10 per month. Team adds governance, compliance, support, and retention features, so the package difference is broader than price alone. Supabase pricing

Billing is organized around an organization with its own subscription and invoice. Each project has dedicated database compute. Some usage allowances are pooled across the organization, while disk allowance is specified per project. A customer adding a project therefore needs to understand both the new compute cost and the allowances shared across the organization. Supabase billing

The Pro Spend Cap covers selected usage. Compute, branching compute, read replicas, and several add-ons are excluded. The documentation says the cap does not provide a separate budget for each usage item or notifications at a customer-selected cost threshold. Coverage and service response matter because a customer may otherwise read cap as a ceiling on the whole bill. Supabase cost control

These are product facts. Whether customers misunderstand them, how often that causes surprise, and whether a different control would change paid growth are hypotheses.

Two useful comparisons

Neon's November 2025 announcement shows one way a provider can change both unit economics and the explanation of compute cost. It is a historical comparison, not proof that one provider is cheaper for a particular workload today. Neon pricing announcement

Vercel lets teams set a spend amount and choose notifications, a webhook, or pausing production deployments. Its documentation also explains that pausing is not immediate. That makes the real tradeoff visible: a control can reduce further exposure while creating service consequences and processing delay. Vercel Spend Management

Five customer scenarios

The interactive model uses constructed scenarios, not measured Supabase segments.

An AI-tool builder may need the cost consequence explained before creating a resource. An independent developer may understand the meters but need a warning when traffic changes. A B2B software team may care about approvals. An AI startup may face volatile background work. An enterprise team may place continuity and accountable spend ownership above a self-service cutoff.

The scenarios expose different control needs. They do not establish segment size, willingness to pay, or production behavior.

Three hypotheses worth testing

Show the consequence at the point of change. A forecast beside a compute upgrade, branch, or new project could help a customer connect the action to the bill. It could fail if volatility makes the estimate look more precise than it is.

Offer a budget with an explicit response. A budget could alert, require approval, or stop selected optional work. A broad stop could damage the application, so the coverage and response need to be chosen and explained together.

Investigate a narrower governance package. The Pro-to-Team transition is a reason to study which governance features block growing teams. A smaller package could create adoption or cannibalize Team. Lost-deal evidence and willingness-to-pay research would decide whether a pricing test is justified.

How to read the model

Choose a customer scenario and one of four pricing structures. The model compares predictability, trust, bill-shock exposure, and provider cost exposure. Every score is a Kelvin-selected pairwise judgment from 0 to 100.

The scores are not produced by a bill calculator and were not fitted to customer or margin data. The model does not predict churn, probability, or Supabase economics. Its job is to make the benefit and failure condition of each structure inspectable.