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.

How many customers do you onboard annually?
The more tenants an organisation onboards annually, the more it will benefit from the pooled deployment model where resources are shared between tenants. Organisations that work in the B2C segment typically onboard 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.

What is your operations budget?
To maintain profitability and a sustainable business model,p SaaS providers must carefully manage their operational expenses, which include both the cost of infrastructure and the salaries of their operations engineers. A common strategy to achieve this is resource sharing, which allows you to optimise resource utilisation and keep costs at a manageable level.

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.

Are there legal, regulatory or contractual concerns that require strong isolation?
Some regulations impose strict requirements on how tenants' data is handled, sometimes requiring complete segregation to prevent unauthorised access or data co-mingling. Additionally, some contractual agreements with enterprise customers or government agencies may require full data isolation as a condition of service. This often makes a pooled tenancy model unfeasible for certain workloads.

Do you need to rollout new features and fixes quickly?
Releases are far easier when customers share the same resources. Updates and bug fixes can be rolled out instantly, so everyone benefits from the latest improvements and security patches at the same time. On the other hand, maintaining dedicated resources for each tenant adds complexity, often forcing customised update plans that slow down feature releases and critical fixes, reducing overall agility.

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.