Every B2B SaaS runs into the tenancy question eventually, usually the day a big prospective customer asks whether their data can live somewhere separate from everyone else’s. I’ve been near this conversation at more than one company now, and the answer always comes down to two options: give each customer their own instance (single-tenant, multi-instance), or run everyone on one shared instance (multi-tenant, single-instance). Neither is “correct”. They just fail in different ways.

Infrastructure Design

#

Single tenant, multi-instance

#

The appeal here is isolation, and nearly every benefit flows from it. Each customer’s data sits in its own environment, so security reviews and compliance conversations get a lot easier. A bad deploy or a heavy workload takes down one customer instead of all of them. You can scale, tune, and customise each instance independently, and dedicated resources mean nobody’s performance depends on what a neighbouring tenant is doing. Maintenance can be scheduled per customer, which keeps downtime small and targeted, and if you price things sensibly you can match infrastructure cost to what each tenant actually uses.

The price you pay is that you’re now running N copies of everything. Resource overhead adds up, configuration drifts between instances, and keeping versions and data in sync across the fleet becomes its own project. Scaling, isolation, and cost management still need real planning. The problems don’t disappear; they multiply.

Multi tenant, single instance

#

This is the default for a reason: one deployment, one database to back up, one version in production. It’s efficient with resources, simple to operate, and every customer gets updates and security patches at the same moment.

The hard parts are the flip side of sharing. One tenant’s heavy usage can drag down everyone’s performance, per-customer customisation is limited, and data isolation now lives in your application code rather than your infrastructure, so a single bug can turn into a cross-tenant data leak. Scalability bottlenecks hit all customers at once, and maintenance needs more care because there’s no “just this customer” blast radius anymore.

Learn more about SaaS Solutions - Multi-instance vs. Multi-tenant Architectures

Multi-tenant vs multi-instance

#

You’ll often see this described as multi-tenant vs multi-instance instead, and it’s the same choice seen from the other side. “Tenant” is about customers: how many share one copy of the software. “Instance” is about deployments: how many copies you run. A single-tenant product is a multi-instance deployment, one copy per customer, and a multi-tenant product is usually a single instance that everyone shares. So when someone asks for multi-instance, they’re asking for single-tenancy.

In practice it’s a range rather than two boxes, and most of the real decisions are about the database. At the most shared end, every customer’s rows sit in the same tables with a tenant_id column, and every query filters on it. That’s the cheapest to run and the easiest to get wrong. One step along, each customer gets their own schema inside a shared database, which gives you cleaner separation and per-customer backups, at the cost of running every migration once per schema. Further along, the application stays shared but each customer gets their own database: a popular middle ground, with strong data isolation and no need to run a whole stack per customer. At the far end is full single-tenancy, with the application and the database both dedicated. AWS’s SaaS guidance calls the two ends silo and pool, and mixes of the two bridge, which is handy vocabulary when you’re explaining your setup to a customer’s security team.

Single-tenant vs multi-tenant at a glance

#

When to use which

#

Go multi-tenant unless something specific pushes you off it. It’s the right default when you have lots of customers paying modest amounts, when people sign themselves up, and when your team is small enough that thirty environments would eat it alive.

Single-tenant earns its overhead in a few situations. Customers in health, finance and government often need their data physically separate, or kept in a particular country, and a dedicated instance is the simplest honest answer to that in a security review. A handful of large customers on enterprise contracts can carry the cost of their own stack, and often expect one. And when customers need their own release schedule, a pinned version or deep customisation, separate instances stop being overhead and become part of what you’re selling.

Where most teams end up is both: a multi-tenant product for nearly everyone, and a dedicated instance as an enterprise tier for the few customers who need it and will pay for it. If the multi-tenant version carries a tenant ID everywhere from day one, moving one customer out to their own database later is a migration rather than a rewrite.

Making multi-tenant isolation harder to break

#

The multi-tenant bug that keeps people up at night is the query that forgets its tenant filter. It doesn’t fail. It quietly returns somebody else’s data, and code review won’t catch every one. If you’re on Postgres, row-level security moves the check into the database, so a query that forgets the filter still only sees the current customer’s rows:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Each request then sets its tenant inside a transaction with SET LOCAL app.tenant_id = '…', so a pooled connection doesn’t carry one customer’s ID into the next request, and a request that never sets it gets an error rather than rows. Two catches: connect the app as a role that doesn’t own the table, because owners skip these policies unless you also add FORCE ROW LEVEL SECURITY, and never as a superuser, which skips them regardless.

Where to start for single-tenant?

#

If you do go single-tenant, tooling decides whether it’s manageable or a slow-motion disaster. You can’t hand-manage thirty environments.

The core is containers plus infrastructure as code. Docker packages the app identically for every tenant, Kubernetes handles deploying and scaling all those instances, and Terraform, Pulumi, or AWS CloudFormation let you define a tenant’s entire stack in code, so spinning up customer #31 is a pull request rather than a lost weekend. If you’re living closer to the VM world, configuration management tools like Ansible, Chef, or Puppet fill the same role. A solid CI/CD pipeline (Jenkins, GitLab CI/CD) matters more than usual here, because every release has to roll out across every instance without babysitting.

Beyond that, it depends on your product’s shape. Serverless (AWS Lambda, Azure Functions) can remove the server layer entirely for some workloads. Managed databases like Amazon RDS or Azure SQL Database save you from administering one database per tenant by hand. Monitoring with Prometheus, Grafana, or New Relic stops being optional once you have a fleet, because you want to know which instance is unhappy before the customer tells you. For identity, a service like Auth0 or Okta handles user management and access control without you rebuilding it per tenant. Whatever language you work in, there’s probably a SaaS-oriented framework or library that saves you some of this plumbing, and any of the big clouds (AWS, Azure, Google Cloud Platform) will host all of it happily.

Don’t buy the whole list on day one. Start with containers and IaC, add monitoring and IAM as tenants accumulate, and let actual pain drive the rest.

The short version

#

Single-tenant, or multi-instance, means a separate copy of the application and database for each customer: strong isolation and per-customer control, and a fleet to run. Multi-tenant means one shared copy: cheap and simple, with isolation enforced in code. Most products should start multi-tenant, with a tenant ID on everything and the database enforcing it, and offer dedicated instances to the few customers who need them and will pay for them. If you do run single-tenant, containers and infrastructure as code are what keep it manageable.