Lesson 6 / 32
Choosing a Tenancy Model
Use concrete questions about tenant count, size, compliance and team capacity to choose a starting tenancy model and evolve it later.
By Rahul Agarwal · 15 years in web development
Questions that decide the model
Choose with evidence, not fashion. Ask: How many tenants? Thousands of small sign-ups push you to pool, because a database per tenant becomes thousands of databases to migrate and back up. How big and uneven are they? If a few tenants are huge, they may deserve their own shard or silo. What do contracts and regulators demand? Banks or hospitals may require dedicated storage, customer-managed keys or data kept in one country. What can your team operate? A two-person team cannot realistically run hundreds of separate stacks. How will you price? Silo costs scale with tenant count, so they suit higher price points. A sensible default for a new B2B product is pool with strict tenant scoping, plus a catalogue so you can later move specific tenants into dedicated resources without a rewrite.
Design for the move, not the final state
You will almost never pick the perfect model on day one. What matters is that tenant placement is looked up, not assumed, and that every row carries tenant_id even in a silo database. That makes later moves between pool and silo a migration job instead of a redesign.
Choosing a vehicle
A startup choosing a tenancy model is like a family choosing a vehicle: a shared auto is cheap for short trips, a private car suits bigger needs, and a bus is perfect for many passengers on one route. You pick for today's trips while making sure you can switch when the family grows.
Quick check: A new B2B product expects thousands of small tenants and has a tiny ops team. What is the most sensible starting point?
- A dedicated cloud account per tenant
- A separate database server per tenant
- Separate code forks per large customer
- A pooled model with tenant_id on every row and a catalogue for future moves
Answer
A pooled model with tenant_id on every row and a catalogue for future moves — Many small tenants and a small team favour pooling. Keeping tenant_id everywhere and a placement catalogue keeps the door open to silo specific tenants later.