What problem does it address?
Provisioning each customer separately can make onboarding slow, costs linear, and operations increasingly manual. The team needs a model it can run confidently without over-engineering the platform.
Constraints to respect
Customer data isolation requirements must be explicit
Existing customers cannot be disrupted during a migration
The team must be able to operate the chosen model
Pricing, quotas, and support boundaries need to remain enforceable
What options should be on the table?
Silo model: separate database per tenant
Pool model: shared database with row-level isolation
Bridge model: shared infrastructure with schema-level isolation
Optimize the current single-tenant model
The recommended decision
Choose the least complex model that satisfies isolation and margin requirements. A bridge model is often a useful starting point, not a default answer.
Outcomes to define and measure
A tenancy decision with explicit trade-offs and a migration plan. Actual cost and onboarding improvements depend on the starting architecture; we publish measured results only with client permission.
Related reading
The thinking behind this pattern
- Microservices vs Monolith: Architecture Decision Guide Microservices vs monolith is a consequential architecture decision. Learn when to choose each, and why a modular monolith often wins first. Read
- Software Development Cost Breakdown: What to Expect Software development costs vary wildly. Learn the real cost ranges, hidden costs, and how to evaluate proposals to avoid overpaying. Read
Want to apply this pattern?
Tell us about your systems and constraints. We will map the pattern to your situation and identify what needs to be verified first.