IMO: Multi-Tenancy Is the Default—Even When You Think It Isn't

A recent FusionAuth article, "The Importance Of Scaling And Why Single-Tenant Applications Are Better," makes a compelling case for the security and performance benefits of infrastructure isolation. However, it overlooks a fundamental reality of modern software: most applications are already multi-tenant by nature, even when we pretend they aren't.

The debate shouldn't be whether to be multi-tenant, but how to do it securely and flexibly.

The "Single-Tenant" Illusion

Let us start by challenging the core definition. Even the simplest applications have multiple classes of users with different data and permissions. Consider a basic e-commerce store, which fundamentally serves two different groups:

• Customers: This group can browse products, manage their own orders, and view their personal data.
• Internal Staff (Admins & Support): This group has elevated permissions to manage inventory, view customer data to resolve issues, and operate the business. These two groups are, for all practical purposes, logical tenants. They use the same application but have strictly partitioned access and capabilities. The idea of a truly "single" tenant is an illusion the moment you have both customers and staff.

For B2B SaaS, Multi-Tenancy Isn't a Choice—It's a Requirement

The need for a tenant-aware design is even more stark in the (business-to-business) B2B world. For example, market leaders like Cloudflare and Vercel don’t provision a new physical stack for every customer; they build on a shared, multi-tenant foundation with strong logical and infrastructural boundaries.

Furthermore, entire industries depend on cross-tenant access. An accountant who can't switch between different client organizations from a single dashboard is an accountant looking for new software. The same is true in healthcare, where a single system must manage distinct clinics, doctors, and patient populations. Large enterprises also require internal tenants for different departments, branches, or business units. In these verticals—from finance and accounting to infrastructure management and healthcare—multi-tenancy is the non-negotiable default.

The Real Security Frontier: Granular, Per-Tenant Control

While isolating infrastructure to protect against "noisy neighbors" or lateral movement is a valid concern, it is only one piece of the security puzzle. The most critical and often-overlooked aspect is the need for granular, per-tenant security settings.

Modern identity platforms must empower administrators to define unique policies for each tenant. Every customer has a different risk profile and unique compliance needs. One tenant might require mandatory multi-factor authentication (MFA) with YubiKeys and strict IP allow-listing, while another might be satisfied with simpler password-based authentication.

A one-size-fits-all security policy, even within a "dedicated" single-tenant instance, is no longer sufficient.

The Architect's Choice: Build for Flexibility from Day One

This brings us to the final, crucial point. It is more difficult to retrofit multi-tenancy onto a single-tenant application than it is to configure a robust, multi-tenant platform for a dedicated, isolated use case.

Starting with a multi-tenant-native architecture provides the ultimate flexibility. You can deploy it in a shared model, an isolated single-tenant mode, or a hybrid in between. The architecture doesn't constrain the business model.

This exact challenge is why we started ZITADEL. We saw a critical need for an identity platform that was built from the ground up on a flexible, multi-tenant foundation, empowering developers to serve any use case without compromising on security.

In the end, choice matters. The future of identity isn't about pitting single-tenant against multi-tenant. It's about demanding platforms that offer both architectural flexibility and the deep, per-tenant security controls that real-world business demands. Security should never be a compromise, and neither should your architecture.