What Is Single-Tenant Architecture?

Single-tenant architecture is a software deployment model in which each customer gets its own dedicated instance of the application and its own isolated data store. In a fully isolated deployment nothing is shared with other customers: separate database, separate compute, separate boundary. In practice isolation is a spectrum, and some designs share a tier such as the application layer while keeping each customer's database separate. The opposite model, multi-tenant, serves many customers from one shared application and one shared database, separating them only by logical partitioning.

The choice between the two is not just an engineering preference. For data platforms that hold sensitive information, it shapes security posture, compliance readiness, and how much control a customer really has. In regulated industries, some customers insist on dedicated infrastructure to meet their regulatory requirements, which is why many vendors offer single-tenant deployments alongside shared ones.

What Single-Tenant Architecture Is

In a single-tenant setup, provisioning a new customer means standing up a new, self-contained instance for them. That instance has its own database, so one customer's data never sits in the same store as another's. It can often run in a location the customer chooses, be upgraded on its own schedule, and be configured to that customer's specific security and compliance rules.

This is different from dedicated hardware alone. The defining trait of single-tenancy is isolation of the data and application boundary per customer, whether that runs on dedicated servers, in a private cloud tenant, or on-premise. The customer is a tenant of one.

Single-Tenant vs Multi-Tenant

The two models make opposite trade-offs. Multi-tenant, the standard SaaS model, runs one application instance and one database for everyone, with logical rules keeping tenants apart. It is efficient: one system to patch, scale, and operate for thousands of customers. Single-tenant runs a separate instance per customer, trading that efficiency for isolation and control.

The practical differences that matter most:

• Data isolation. Single-tenant keeps each customer's data in its own store; multi-tenant relies on logical separation within a shared database.
• Blast radius. A misconfiguration or breach in a shared database can expose multiple tenants; single-tenant usually limits the impact to one.
• Compliance. A dedicated store is easier to evidence for the security-of-processing duty in Article 32 GDPR and in ISO/IEC 27001 or SOC 2 audits, which is simpler than proving watertight logical separation.
• Location and control. Single-tenant instances can more easily meet residency and sovereignty requirements, because the whole instance can run where the customer needs it.

Why Single-Tenant Matters

For a platform that holds sensitive data, single-tenancy addresses risks that logical separation cannot fully remove.

Security. The biggest cross-tenant risks, one customer reaching another's data through a bug or misconfiguration in shared infrastructure, are largely removed when there is no shared store. Isolation then comes from the deployment boundary itself, so it depends far less on application rules that could fail. Microsoft's architecture guidance puts it plainly: with a dedicated deployment per tenant, data for each tenant is isolated, "which reduces the risk of accidental leakage."

Compliance. Auditors like clear boundaries. Demonstrating that a customer's data lives in a dedicated store, in a known location, is more straightforward than proving that logical partitioning in a shared database is airtight. It gives a clear boundary to document under GDPR and in ISO/IEC 27001 or SOC 2 audits.

Control. A dedicated instance can run where the customer requires, be upgraded on their schedule, and be tailored to their policies, which matters for residency and sovereignty commitments.

The Trade-Offs

Single-tenancy is not free. Running a separate instance per customer costs more in infrastructure and operational effort than a single shared system (Microsoft's guidance notes that if one tenant needs a given infrastructure cost, 100 tenants probably need 100 times that cost), and upgrades have to be rolled out across many instances rather than one. Multi-tenant remains the more efficient model at scale, and for non-sensitive workloads that efficiency is often the right call.

The right choice comes down to fit. Multi-tenant suits high-scale, lower-sensitivity applications. Single-tenant suits sensitive, regulated, or sovereignty-bound data where isolation and control outweigh the efficiency of sharing. Some providers mix the two, running most customers on shared infrastructure and giving dedicated deployments to those that need them. What decides it is the data you are protecting.

How Dawiso Fits

For a data catalog, the question of isolation comes down to where your metadata lives, and Dawiso's deployment options let you decide that.

• Three deployment models. Dawiso runs as SaaS on Microsoft Azure, in a private cloud in your own cloud tenant, or fully on-premise.
• A dedicated instance when you need one. In a private cloud or on-premise deployment, the Dawiso instance and its metadata run inside infrastructure your organization controls, which can help you meet your residency and sovereign cloud requirements.
• Metadata in hybrid setups. Where metadata is collected inside your environment and sent to Dawiso in the cloud, only metadata is transferred, plus any data samples you choose to enable.
• The architecture decides. Dawiso does not decide where your data resides or control access to your source systems; the deployment model you choose does, by determining where your metadata is stored and who operates it.

For how this fits the wider sovereignty picture, see European data sovereignty and the data catalog.

Conclusion

Single-tenant architecture gives each customer an isolated instance and data store, trading the efficiency of shared infrastructure for stronger isolation, simpler compliance documentation, and more control. Multi-tenant remains the efficient default for high-scale, lower-sensitivity applications, but for regulated and sovereignty-bound data, single-tenancy sharply reduces cross-tenant risk. When the data is a full map of your estate, as a data catalog is, a dedicated deployment is the more cautious foundation.

Sources

• Microsoft Learn, Tenancy models for a multitenant solution, Azure Architecture Center.
• GDPR, Art. 32 GDPR: Security of processing.
• ISO, ISO/IEC 27001:2022 - Information security management systems.
• AICPA & CIMA, System and Organization Controls: SOC Suite of Services.
• Dawiso, Enterprise Deployment.