You get 10x tenants next quarter, 100x next year. What breaks first, and how do you know?

The full executive answer

Honest answer: the compute tier essentially does not break — the database tier is the first pressure point, and we have designed for that. The application layer is serverless: Vercel spins up as many function instances as traffic demands, so 10x tenants means 10x concurrent functions with no capacity planning from us. The classic failure mode of that pattern is that thousands of short-lived functions exhaust Postgres connections — Postgres handles hundreds of connections well, not tens of thousands. That is why every connection goes through Supabase's pooler (Supavisor, their PgBouncer-equivalent), which multiplexes many function connections onto a small pool of real database connections.

At 100x, the next pressure points are query cost and single-instance write throughput. Our defences: strict pagination discipline everywhere (we page through large tables in 1,000-row windows, enforced as a code convention, so no query degrades into an unbounded scan), an AI response cache so repeated analysis never re-hits the model or recomputes, and per-key rate limits per minute and per day so no single tenant can consume the platform. Beyond that, Supabase Postgres scales vertically a long way, read replicas are a configuration change, and our architecture is already cell-based — the EU and India cells are config-ready, and cells are also a horizontal scaling unit, not just a residency one.

What I will not do is quote you throughput numbers from load tests we have not run at that scale. We are pre-launch with no production load history — that is stated plainly in our own documentation. The compensating control is that every layer we chose (Vercel, Supabase, pooled Postgres) has public evidence of operating at orders of magnitude beyond our 100x scenario, and formal load testing is on the pre-GA roadmap before we sign capacity-sensitive contracts.