// A pattern for architecting around the largest hidden COGS line in most B2B SaaS companies, before it becomes the reason you can't raise prices.
Most B2B SaaS founders never run the per-customer math on their database. They run the gross number — our DB bill is $X this month — and feel either relieved or vaguely anxious about it. The interesting question is the one almost nobody asks: what does it cost to serve our median customer, and what does it cost to serve our top 10%?
When teams finally run that math, the answers are reliably ugly. The top 1% of customers consume 30% of the database. A handful of free-tier accounts have data shapes that hammer one shared index. The "enterprise tier" with bigger feature flags actually has lower per-seat margin than the team tier, because of one query pattern that nobody priced.
This is the hidden side of multi-tenancy. The system runs fine. The economics don't.
Three tenancy patterns, three cost profiles
Shared-everything. One database, one schema, a tenant_id column on every row. Cheap to operate at low scale, painful to operate at high variance — a noisy tenant degrades performance for everyone, and you can't easily migrate one customer to a different region or compliance footprint without surgery.
Shared-database, per-tenant schema. One DB instance, separate schemas per tenant. Slightly better isolation, slightly worse operational story (migrations are now N-times more expensive). Good fit for mid-market SaaS with a low hundreds of customers.
Pooled-isolated. Shared infrastructure, but each tenant gets dedicated compute and storage that you actively shape — its own RDS instance, its own database cluster, sometimes its own VPC. Expensive to operate, easy to reason about, the only realistic pattern for true enterprise workloads.
Most companies choose the first pattern by default — it's what the framework's quickstart produces — and stay there until something hurts.
What actually drives per-customer cost
Run the audit. For each tenant, you want to know:
- Storage footprint. GB of data on disk per tenant, including backups and indexes (don't forget the indexes).
- Query volume. Queries per second per tenant, weighted by their actual cost in IOPS.
- Hot rows. How concentrated is the read pattern? A tenant whose hot working set is 10x the median is a tenant whose cache hit rate is single-handedly degraded.
- Write fan-out. Every write that triggers a downstream — index update, materialized view refresh, change-data-capture event — multiplies per-tenant cost.
Sort tenants by total cost. The shape is almost always a power law. The top decile is consuming somewhere between 40% and 70% of total infrastructure cost. The bottom decile is consuming approximately nothing.
That distribution is the entire pricing conversation.
The pricing pattern that follows
Once you have the cost-per-tenant distribution, three rules become obvious:
Price the top decile differently. If 10% of customers are 50% of cost, they need their own price tier. This is not a "feature" tier — it's a capacity tier, priced for the resource consumption you can predict from their workload. Call it an enterprise tier if you want, but the underlying mechanic is matching price to cost.
Meter the things that drive variance. Storage. API requests. Inference calls. Anything that scales unpredictably with how the customer uses the product should appear as a usage-based line item, not as a hidden subsidy buried in a seat price. You don't have to charge much per unit — but the meter itself does most of the behavioral work.
Refuse free-tier shapes you can't afford. A free tier with unlimited storage, retained forever, is a liability that grows on its own. A free tier with 30 days of retention and a generous-but-finite storage cap behaves like a free tier and operates like a paid one. The unbounded version of any feature is a unit-economics trap waiting to spring.
The architectural decision underneath the pricing one
Pricing without architecture is a memo. To actually act on the distribution above, you usually need to do one of two things:
- Move the top decile to pooled-isolated. The biggest customers get their own database — possibly their own region — and you pay the operational cost explicitly and price it explicitly. Their workload stops degrading everyone else's, and you stop subsidizing them.
- Implement tenant-level rate limits and quotas. If you can't move them off shared, at least prevent them from monopolizing the shared resource. A simple per-tenant request budget catches the worst behavior — but it doesn't fix the underlying margin shape; it just stops the bleeding.
In practice, most companies do both — pooled-isolated for the top tier, shared-everything with quotas for everyone else, with a clearly documented migration path between them.
The thing this essay is really about
Pricing the multi-tenant database is not really about the database. It's about understanding that infrastructure cost is not flat across customers, that the distribution is heavily skewed, and that the right price for a customer is downstream of the cost to serve them — not the other way around.
Founders who run this math early have boring pricing conversations and predictable margins. Founders who don't run it have a six-month sprint, eighteen months in, to retrofit usage-based pricing into a customer base that has gotten used to all-you-can-eat. That's a much harder conversation. Have the easier one first.