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. Nothing is shared with other customers: separate database, separate compute, separate boundary. 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 and sovereignty-conscious organizations, single-tenant has moved from a premium option to a requirement.

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 contains the impact to one.
• Compliance. A dedicated store can be evidenced against GDPR, ISO 27001, or SOC 2 requirements on its own terms, 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, simply do not exist when there is no shared store. Isolation is structural, not enforced by rules that could fail.

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 maps cleanly onto GDPR, ISO 27001, and SOC 2 expectations.

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, 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 honest framing is fit, not superiority. 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. The question is not which is better in the abstract, but which matches the data you are protecting.

How Dawiso Fits

Dawiso applies single-tenant principles where they matter most: your metadata.

• A separate metadata store per customer. Dawiso does not use a shared multitenant database. Each customer has its own metadata store, removing cross-tenant exposure by design.
• Compliance-ready isolation. That dedicated store supports GDPR, ISO 27001, and SOC 2 obligations on its own terms, rather than depending on logical separation inside a shared system.
• Deploy where you need it. Combined with private cloud or on-premise deployment, single-tenancy lets the whole instance meet your residency and sovereign cloud requirements.
• Metadata-only in hybrid setups. Where Dawiso runs alongside your systems, only metadata is transferred and your sensitive data stays in your environment.

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, cleaner compliance, and more control. Multi-tenant remains the efficient default for high-scale, lower-sensitivity applications, but for regulated and sovereignty-bound data, single-tenancy removes an entire category of cross-tenant risk. When the data is a full map of your estate, as a data catalog is, a dedicated store per customer is the safer foundation.