Single-tenant vs multi-tenant SaaS: what a dedicated server per customer actually changes

Multi-tenant SaaS runs many customers on one shared application and, usually, one shared database. Each row carries a tenant identifier, and the software is responsible for making sure customer A never sees customer B's data. Single-tenant SaaS gives each customer a separate instance of the application with its own database, often on its own server. The vendor still runs and updates it; the customer simply does not share it.

Both are legitimate architectures, and most software you use is multi-tenant for good economic reasons. The differences matter most for systems that hold a whole company's customer, financial and operational data, which describes a CRM or ERP. This article compares the two models on the points that affect a buyer, and lists the questions that reveal which model a vendor really runs.

The two models side by side

Isolation: where the boundary sits

In a multi-tenant system, the line between customers is drawn by software. Every query must include the right tenant filter, every cache key must include the tenant, every background job must run in the right context, every file path must be scoped. Good vendors enforce this in the database itself with row-level security policies, so a forgotten filter in application code fails closed. Even so, the boundary is a set of rules applied to shared data, and a mistake in those rules is a cross-customer incident.

In a single-tenant system the boundary is the database itself. A bug in a report query can only ever read the one customer's data, because no one else's data is there. That does not make the application safe: a customer can still be exposed by a weak password, a missing permission check inside their own workspace or an unpatched server. What it removes is the specific failure where one customer sees another.

The models in between

Real deployments sit on a spectrum rather than at two poles, and vendors use the words loosely. Four common patterns, from most shared to least:

• Shared everything: one application, one database, one set of tables, a tenant ID on every row.
• Schema per tenant: one database server, but each customer has their own set of tables. Better separation, still shared resources.
• Database per tenant: a shared application fleet connects to a separate database for each customer. Data is physically separated; compute is not.
• Instance per tenant: each customer has their own application and database, often on their own server or virtual machine.

When a vendor says "isolated", ask which of these they mean. Each step down the list narrows the blast radius and raises the vendor's operating cost, which is why the last two usually come with higher minimum prices or require strong automation behind the scenes.

For a CRM, that distinction matters more than for most software. A single cross-tenant leak would expose customer lists, deal values and conversations, the most commercially sensitive data a company holds.

Performance and noisy neighbours

On shared infrastructure, one customer's heavy job competes with everyone else's. A large CSV import, an automation stuck in a loop or an analytics query over millions of rows can slow the system for other customers, which is why multi-tenant vendors impose rate limits, quotas and queue priorities.

A dedicated server avoids the problem by giving each customer their own CPU, memory and database connections. The trade-off is that a customer's capacity is whatever their server has, so a single-tenant vendor needs monitoring per instance and a way to resize one customer without touching the rest.

Updates, releases and control

Multi-tenant products update everyone at once. That is efficient and means every customer is always on the latest version, including every new bug.

Single-tenant products roll updates out instance by instance. A vendor can release to a small group first, watch for problems and continue, and a broken release can be stopped before it reaches most customers. The cost is operational: the vendor must automate releases well, or customers drift onto old versions. Ask how quickly a security fix reaches every instance, not just whether instances are separate.

Backups, restores and leaving

A backup is only as useful as the restore it enables. In a shared database, restoring one customer to yesterday without rolling back everyone else requires extracting their rows from a backup and merging them into live data, which is slow and error-prone. Many multi-tenant vendors therefore offer exports but not true point-in-time restores for a single customer.

In a single-tenant deployment, a customer's backup is a complete copy of their own database, and a restore replaces only their instance. The same property makes leaving easier: a full export is a natural by-product rather than a special project.

Questions worth asking any vendor, whichever model they run:

1. How often are backups taken, and how long are they kept on my plan?
2. Can you restore only my workspace to a point in time? How long does it take?
3. Can I export everything myself, including files and history, in a documented format?
4. What happens to my data and backups after I cancel, and for how long?

Data residency and compliance

Data protection rules such as the GDPR care about where personal data is processed and who can access it. In a multi-tenant system, every customer's data lives wherever the shared cluster runs; offering a choice of region means running and operating separate clusters. In a single-tenant system, each customer's server can be placed in a chosen region by design.

Residency is not only about the main database. Ask where backups, logs, file storage, search indexes and AI processing happen, because each of those can sit in a different country from the database.

When multi-tenant is the right choice

Single-tenancy is not automatically better. Multi-tenant products are cheaper, often faster to start, and run by vendors who can concentrate their security investment in one place. For tools that hold little sensitive data, or for very small teams on tight budgets, a well-run multi-tenant product is often the sensible pick. What matters is that the vendor can explain how isolation is enforced, and that the controls match the sensitivity of what you are putting in. A note-taking app for a team of four and the system that holds every customer, invoice and contract of a growing company deserve different answers, even if both are sold as SaaS.

How Nextora is deployed

Nextora runs every paid workspace on its own dedicated server, hosted in the EU. Each workspace has its own application and its own database, so one customer's data never shares a database with another's. Two things do leave the workspace server: AI requests pass through Nextora's AI gateway to the model provider, and off-site backups are stored separately from the server they protect. During the 14-day trial a workspace runs on shared trial infrastructure; after the first payment it moves to its own server. Updates are released to workspaces in stages rather than all at once.

Backups are kept for 7 days on Starter, 30 days on Growth and 90 days on Scale, and are visible in the customer account. Inside the workspace, administrators can export one record type as CSV or a full backup of the whole workspace as JSON. Isolation between workspaces is one layer; within a workspace, roles decide who sees and changes what, an audit log records sign-ins, edits and permission grants, and deleted records go to a recycle bin with a retention period you set. Plans and retention are on the pricing page.

A vendor checklist

• Is my data in a database shared with other customers? If so, how is separation enforced, and is it enforced in the database?
• Where are the servers, backups, logs, files and AI processing located?
• Can one customer's heavy usage affect my performance?
• How are updates rolled out, and how fast does a security fix reach every customer?
• Can you restore only my data to a point in time, and can I export everything myself?
• Who at the vendor can access my data, and is that access logged?

Architecture protects the boundary between companies; permissions protect the boundaries inside yours. Designing CRM roles and permissions covers the second half. For the cost side of the decision, see per-seat vs flat CRM pricing.