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 business 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. A hybrid approach often works well. Shared resources keep things cost-effective for smaller customers, while dedicated setups give enterprise clients the isolation and customisation they expect.

B2C providers with lots of tenants usually lean towards pooled models, whereas B2B providers tend to mix dedicated stacks for larger customers with shared infrastructure for the rest. If tenants need deep infrastructure customisation, a siloed model may be a better fit.

Data residency is another key factor. Some customers are bound by regulatory or contractual rules requiring fully isolated data, which drives out pooled setups for those workloads. Regional laws also dictate where you can host, replicate, and back up data. Getting it wrong risks compliance breaches, legal headaches, and lost trust. Best to bake these requirements into your architecture from the start.

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.