Tenancy model

In SaaS, the tenancy model determines how tenants’ resources are deployed. This is a spectrum which ranges from fully isolated, where a dedicated stack is deployed per tenant (silo), to fully shared, where all tenants share resources and rely on logical isolation measures (pool). In reality, though, SaaS providers often sit somewhere in the middle, especially in a B2B segment. When deciding on the optimal tenancy model for a SaaS application, SaaS providers are essentially choosing how to balance isolation, cost, scalability, and operational complexity.

Siloed deployment model is usually more clear and simple approach to start with. This is why organisations that transition from traditional software models, more often prefer to deploy their tenants separately rather than deploying them to shared resources.

Resource separation provides not only quicker launch of SaaS offering for traditional software businesses, but simplifies tenant cost allocation, by allowing to tag dedicated tenant resources, which opens additional opportunities for monetisation and profit margin optimisations. For example SaaS providers can easily identify customers with low, or even negative, profit margin and adjust their pricing model or consumption quota appropriately.

Another advantage of the siloed deployment model is the relatively straightforward implementation of tenant data isolation, reducing the risk of data leakage or cross-tenant interference. This level of separation is particularly valuable for organisations operating in sectors such as finance, healthcare, or government, where compliance requirements require strict data isolation.

Additionally, isolating environments limits the impact of failures, significantly reducing the risk of cascading issues across tenants and improving overall resilience. It also prevents performance degradation caused by noisy neighbours, ensuring predictable and consistent service quality for all tenants.

However, a siloed tenancy model comes with several challenges, the most significant of which is cost. It’s difficult to use resources efficiently when each customer has a full copy of the resource stack. Even with elastic scaling, there is always some degree of underutilisation that leads to wasted capacity. As your business grows to thousands of customers, this waste multiplies significantly. A practical way to address this challenge is to use serverless resources with a usage-based pricing model.

Customer growth presents another major challenge. Growth becomes harder when each customer requires their own application stack to be deployed, updated, and maintained, especially if these stacks are highly customisable and differ from one customer to another. This slows growth and reduces agility.

And finally, maintaining separate Dev, UAT, and Prod environments for each tenant proportionally increases the infrastructure footprint and maintenance overhead, further undermining growth and profitability.

SaaS-first applications, especially in the B2C segment, typically launch with a pooled tenancy model because it simplifies infrastructure management and reduces initial costs. In this setup, compute, storage, and networking resources are shared across all tenants, making scaling more efficient.

The pooled tenancy model offers a significant cost reduction per tenant. By distributing infrastructure costs across a larger user base, SaaS providers can offer more competitive pricing compared to dedicated, siloed environments. This shared resource allocation makes pooled tenancy an appealing and economically viable option for many businesses.

This is especially important for SaaS providers that want to onboard small tenants. Instead of providing dedicated infrastructure, which can be expensive, SaaS providers can use shared resources to profitably serve smaller customers. This approach makes it cost-effective to onboard small tenants, expanding the SaaS provider's potential market.

Sharing tenant resources not only cuts costs, but also makes businesses more agile. Since you only have one application instance to maintain, you can deploy updates and new features faster and more consistently to all tenants. This approach reduces complexity, which allows for quicker innovation and easier scaling as SaaS business grows.

Moreover, pooled tenancy model enables businesses to scale more efficiently. Instead of replicating an entire application stack for each new tenant, organisations can simply onboard them into the existing environment, saving both time and resources. This approach accelerates growth while reducing operational overhead and complexity.

While cost-effective and agile, pooled tenant deployment model can introduce challenges with isolation, compliance, and customisation. A common pattern for B2B SaaS providers is to start with a fully pooled tenancy model, where all customers share the same infrastructure. However, as they take on larger clients, these providers often shift towards a more siloed approach. This is because bigger customers typically need more customisation and stronger isolation for their data.

In a pooled tenancy model, multiple customers share the same underlying resources, which increases the risk of accidental access across tenants. This makes it absolutely necessary to implement robust logical data isolation measures to ensure that tenants’ information remains secure. As a result, meeting regulatory and compliance requirements becomes more complex, often requiring additional controls, monitoring, and auditing mechanisms.

Additionally, it's difficult to track individual tenant usage because resources are shared. This lack of granular data makes it challenging to accurately allocate costs to each tenant based on their actual consumption, which can hide how profitable individual customers are. While it's possible to create a good cost allocation system in a shared environment, it often adds complexity and increases the overall costs.

The "noisy neighbour" problem is another challenge that comes with the pooled tenancy model. This happens when one tenant's high resource usage negatively impacts the performance for other customers sharing the same infrastructure. Without strong isolation between tenants, this can lead to frustration, reduced trust in the service, and cause customers to leave. This kind of dissatisfaction can damage a company's reputation and undermine business growth.

As you can see, there is no "good" or "bad" tenancy model. Each organisation has to find the right balance between shared and dedicated tenant resources. This decision depends entirely on their unique needs and specific requirements.

Choosing the right tenancy model is a crucial step when building a SaaS product, as it directly impacts its scalability, cost, and security. To make an informed decision, SaaS provider should consider the following questions.

What is your target number of customers?
The more tenants SaaS application has, the more it will benefit from the pooled deployment model where resources are shared between tenants. Organisations that work in the B2C segment typically have more tenants and therefore fall closer to the fully shared side of the spectrum, whereas organisations that work in the B2B segment usually combine a dedicated stack for enterprise-grade tenants with shared resources for smaller tenants.

Are you targeting both small and enterprise customers?
To effectively target both small and enterprise customers and increase market coverage, a SaaS provider can implement a hybrid tenancy model. This approach combines the cost-effectiveness of shared resources for smaller customers with the strong isolation and customisation of dedicated resources for larger enterprises.

Do your customers need heavy customisations or version pinning?
For tenants that need heavy customisations or version pinning, the siloed tenancy model can be a good fit. This approach provides each tenant with their own dedicated instance of the application and infrastructure, allowing for deep customisation without affecting other tenants.

What level of isolation do your customers expect?
Some regulations or contractual obligations require full isolation of tenants’ data to guarantee protection against unauthorised access or data co-mingling. This often makes a pooled tenancy model unfeasible for certain types of workloads.

What are your data residency requirements?
SaaS applications must comply with regional laws and regulations. These requirements directly impact your architecture choices, such as which cloud regions you can use, and influence design decisions around replication, backup, and failover. Ignoring them can lead to compliance violations, legal risks, and loss of customer trust.

Finding the right balance between siloed and pooled tenancy models requires you to work backward from your business model and specific needs. Since a business is never static, you'll need to continuously adapt your architecture to align with its evolving requirements.