Every B2B SaaS founder we’ve worked with eventually asks the same question: should we go multi-tenant or dedicated? The honest answer is “both, in stages, and the staging matters.” Here is the decision tree we walk through.
Three real options, not two
The debate usually gets framed as a binary: shared infrastructure with logical isolation versus a dedicated stack per customer. There’s a third option in the middle that almost nobody discusses upfront — physically isolated tenants on shared infrastructure (separate database, shared application servers, shared cluster). It’s where most successful SaaS products end up.
We call them shared, isolated, and dedicated. Each has a different cost curve, a different security posture, and a different operational story.
Shared: optimal for the first 100 customers
One database. A tenant_id column on every row. Row-level security in Postgres if you want belt-and-suspenders. Every query takes the tenant context from the authenticated session. This is the cheapest model to operate, the fastest to ship features for, and the easiest to debug.
It fails when one customer’s data volume distorts the shared schema (analytics queries become slow for everyone), when a security review demands data isolation as a contractual term, or when you start signing customers in regulated industries.
Isolated: the migration most teams underestimate
A database per tenant, application servers shared. The application code grows a tiny middleware that switches the connection per request. Migrations now have to run against N databases instead of one. Backups are per-tenant. Analytics across all tenants requires a separate warehouse pipeline.
The gain is real: noisy customers don’t affect the others, security audits stop blocking deals, and you can offer per-tenant data residency by deploying isolated databases in a customer’s preferred region. The cost is operational. We’ve watched teams underestimate the migration twice.
Dedicated: a different product
A dedicated stack means the customer gets their own application servers, their own database, their own cache, often their own subdomain or even their own AWS account. This is the model we use for Phoned-CRM enterprise customers. It is not a SaaS feature; it is a different business model. You charge per stack, not per seat.
Dedicated unlocks compliance markets that the other models cannot reach (some health and finance regulators require it). It also requires a deployment pipeline that can spin up a complete environment in under an hour, observability that’s per-stack, and a billing model that reflects the cost.
How to choose
The decision tree we use:
- Are you signing your first ten customers? Shared. Always.
- Is your average contract value above $50k? Plan the isolated migration now, not later.
- Are you selling into healthcare, banking, or government? Dedicated, with isolated as a fallback for smaller customers in the same vertical.
- Are you trying to land one specific large customer who needs dedicated? Build it for them, but invoice them for the engineering cost — don’t subsidize a single deal with future product velocity.
The one thing nobody tells you
Migrating from shared to isolated is hard but doable. Migrating from isolated to dedicated is also doable. Migrating backward — from dedicated to isolated — is a multi-quarter project with no customer-visible upside. Don’t go dedicated until you have to.