Data Engineering for Multi-tenancy

How Multi-tenancy is Operationalized in B2B SaaS - A Verb Exclusive

How Multi-tenancy is Operationalized in B2B SaaS – A Verb Exclusive


Did you know? Until the 19th century, there were only stand-alone homes, bungalows, and townhouses in the USA. Buildings that can be shared by multiple tenants (or “apartments,” as we know them today) came into the picture only in the early 1900s. Even so, skyscrapers were out of the question in the initial phases. The first “apartments” were just 5 stories high until our architects found new and ingenious ways to scale them up!

This idea of creating structures and spaces that can be “shared” by “multiple “tenants” also finds resonance in Data Science. Commonly referred to as “multi-tenancy”, it is an integrated environment that caters to multiple tenants or customers using scalable and elastic architecture. Multi-tenant data architecture is especially useful when it comes to B2B SaaS, where a single application crafts unique data experiences for multiple client organizations.

However, multi-tenancy is easier said than done. Along with unprecedented scale, one also has to cope with unprecedented development and operational complexity.

As a no-code dashboard development solution purpose-built for B2B Saas products, today we share with you the complexities and trade-offs when deploying sophisticated data engineering for multi-tenant applications.


The Different Kinds of Multi-tenancy Models

Before we go into the finer details of multi-tenancy, here’s a quick recap. A single-tenant architecture is one where each client “owns” its share of the hardware and software ecosystem. It is a stand-alone architecture that is specific to a client. However, in a multi-tenant architecture, this concept of “ownership” is tossed aside. Instead, clients “rent” a slice of the application environment. Each client acts as a “tenant” (hence the term, “multi-tenancy”).

This means that if a B2B SaaS company serves 200 clients, for example, it will not have to replicate the entire suite 200 times. Instead, it will simply allocate a portion of the application to each client when onboarding it. This saves costs, engineering time, and maintenance efforts, and also helps to scale faster.

Different flavors of multi-tenancy are used for the diverse data needs of SaaS product owners and their customers. Broadly speaking, the multi-tenancy logic can be applied to the underlying database architecture and data engineering in 4 key ways.

#1 Single Database Multi-tenancy (Pool Model)

A good example of single database multi-tenancy or the “Pool Model” is Hubspot or Google Drive, where one application/data environment services multiple tenants. It is a relatively simpler, faster, and less complicated approach. For any data operation, every time only a single application is queried. There is one database, one deployment instance, and one underlying schema for everybody, making it faster and more efficient.

Since multiple users share the same infrastructure, weaker boundaries exist between tenants, increasing the risks of data breach and cross-tenant exposure.

#2 Siloed Multi-tenancy

Here, infrastructure and resources are partitioned into silos using, with each silo being allocated to each client. This is useful when one needs to establish stricter boundaries between tenants, or when one has to accurately calculate the resource usage of each client frequently. However, this also means that development complexities (like schema changes) arise when the relationship between objects changes. 

Simply put, in the Siloed model, the tenant data of one client is fully insulated from any other tenant data. This makes it more secure. But the increased need for resources and code replication increases data engineering labor. Furthermore, multiple instances of deployment multiply the number of points of failure. Every time a new client is to be onboarded, additional costs, engineering man-hours, and management time need to be allocated.

#3 Bridge Multi-tenancy

The bridge model “bridges” the gap between the two extremes – i.e. the Pool and the Silo models. While partitions exist between tenants, there are also shared infrastructures that are common. For example, multiple tenants can share the same public domain data, industry databases, and web servers but microservices may be isolated and separately deployed for different users.

At Verb, we use a slightly modified version of the bridge model. Although it is a great middle point for SaaS developers that rests between the two extremes, there are still some finer loose ends that need to be tied up. For example, the degree of variation and separation for each tenant of a B2B SaaS company is not really a science. Rather, it is an art. It is arrived at by understanding the unique demands of the industry that SaaS company serves. This means that the kind of partition we would do for a SaaS product serving footwear brands won’t probably be the same as that for a SaaS product that serves restaurants and eateries. 

Similarly, any sharing of resources and schema between tenants is itself a double-edged sword. We use the logical equivalent of a “partitioning key” to ensure that this kind of fluidity does not lead to any mismanagement or tenant exposure.

#4 Tier-based Multi-tenancy

Not all customers wanted a shared experience with other tenants. However, not all customers can bear the costs of a fully siloed architecture. Given this, the tier-based model is a leg up from the bridge model. It allows clients to choose between co-habitation and isolation, co-mingling and partition.

Enterprise customers often prefer siloed multi-tenancy owing to compliance burdens as well as the overall security quotient. They are also usually deep-pocket enough to shoulder the costs. Smaller customers like startups, for example, might be okay with having their data resources co-mingled and cohabitated if it means leaner operations and lower costs.

The tier-based model allows these various needs to be addressed through simple a subscription model. Hence, the flexibility is much higher, leading to better customer satisfaction and retention. However, this also leads to compounded security rules for each client and the proliferation of application logic to accommodate varying tolerance of multiple clients to cohabitation.

With Verb, however, such micromanagement of multi-tenancy complexities (and the engineering effort required to tackle it) ceases to be your headache. We enable a fully automated provisioning of resources and infrastructure in multi-tenancy environments while ensuring that data security, scalability, and speed are never compromised. Onboarding new customers and attuning to the requests of existing customers is easy, quick, and simple – not to mention completely no-code!

The follow-up to this article is “Exploring Options for Multi-tenant Database Model“.

If you want a tour of our newest features get in touch!