Exploring Options for Multi-tenant Database Model

Verb’s unique approach to making the multi-tenant database model work provides the greatest cost and time advantage for SaaS companies.

How Verb Provides the Best of Both Worlds for Multi-tenant Database Models


The marriage between B2B and SaaS is not an easy one. Then again, marriages seldom are!

Humor aside, one of the key capabilities that a B2B SaaS app is evaluated on is its ability to provide hundreds of clients with data-backed, actionable insights. The catch? The data needs of B2B SaaS customers need to be served at scale without compromising on the richness and flexibility of data visualization for each client.  Furthermore, often, this needs to happen in near real-time, and in a self-service manner.

At Verb, helping B2B SaaS companies to walk this tightrope between speed-cum-scalability of data experience at one end, and client satisfaction at the other has been at the heart of everything we do.

To be fair, there is a wide array of options to design database models for SaaS products. These include database-per-tenant, multi-tenant databases, single multi-tenant databases, and shared multi-tenant databases. Put simply, the high-level concept is as follows.

In single tenancy, each database stores data from only one tenant or customer, whereas in multi-tenancy, each database stores data from multiple tenants or customers. This enables the reusability of code, schema, and other data resources.

In this blog, we take a sneak peek into Verb’s unique approach to making the multi-tenant database model work to provide the greatest cost and time advantage for SaaS companies. Through this approach, we have been able to make B2B SaaS customer dashboards easy, customizable, and high performing in the shortest possible turnaround time. A precursor to this article on the different types of multi-tenancy models is here.


#1 Scalability by Design for Multi-tenant Database

Horizontal and Vertical Scaling with Verb’s Multi-tenant Database Model

In the B2B SaaS model, each customer is like a tenant of your company. The multi-tenant database acts on a sharing basis by “renting” out data storage, data assets, and data analysis/visualization components to all your tenants, or customers.

Now, what would a B2B SaaS company do if it wanted its customer dashboard to be shared with 50K users spread across 100 customers?

Let’s consider the options for a moment.

Option 1: Traditional Approach

The company could set up 50,000 instances of the app’s data, analytics, and visualization modules, leading to massive wastage of data resources. Scalability is tossed out of the window.

Option 2: Multi-tenancy Approach

Since all users within a customer organization have access to identical data, multi-tenancy can group the data-sharing instances based on customer accounts. Scalability is higher here, but still not optimal.

Option 3: Verb’s Approach to Multi-tenant Database Models

Verb’s architecture combines vertical and horizontal scalability to build up further on the existing practices around multi-tenancy. While data components are distributed on the basis of the customer account (same as option 2 above), they are also divided across user profiles/roles (out-of-the-box user segmentation). This user profiling cuts across organizations and helps address asynchronicity and concurrence among all data assets and resources.

Using the multi-tenant database model, Verb enables SaaS companies to provide integrated, real-time data visualization to any number of clients using the same codebase, database, and deployment configurations.

Verb’s no-code customer dashboards are deployed in a distributed architecture with multiple instances running on many nodes. Hence, Verb’s horizontal and vertical scaling work hand-in-hand with the virtualization of data resources and components across all user instances.

#2 Tenant Isolation with Verb

Ensuring Data Security by Implementing Application-level Separation of Tenancy

The very nature of the multi-tenant database model is that each product instance handles requests from multiple tenants simultaneously. Hence, the infrastructure by itself can’t provide the necessary tenant isolation. Verb takes the bull by the horns by using application logic to solve this problem. Put simply, it applies controls to keep each tenant’s data separate.

Tenants can be isolated using schema, tables, or by applying tenancy logic to the ops layer. But in reality, development complexity and challenges in implementing leak-proof isolation persist. Verb makes sure that tenants can’t deliberately or accidentally access each other’s data assets or analysis components. But tenant isolation in a multi-tenant data model is much more than just that. 

For example, Verb’s model ensures that for each tenant:

  • Activity and performance are not impacted by the workload of other tenants.
  • Per-tenant database costs are clearly calculable and trackable.
  • Tenant-specific or tenant class-specific customizations in the database model can be implemented without affecting other tenants.

This means that with Verb, database models for your customer dashboards are configured in such a way that both large and small customers can benefit equally. Our dynamic and elastic scaling data resources ensure that small customers are not starved while big customers can expand exponentially.

#3 A Penny Saved is a Penny Earned

How Verb Uses Multi-tenancy to Save Time and Cost-to-serve

A major pitfall of multi-tenancy is the inability to track and respond to the usage needs of data resources and the workload of each tenant. Some clients may consume a lot more resources than others, so equal distribution is clearly not the answer here.

Pareto’s 80-20 rule is often seen in action here. That is, 20% of the clients of a B2B SaaS company may end up consuming 80% – the lion’s share – of the company’s resources. In fact, excessive overutilization by even a single client can cause the server to crash.

Verb solves the problem by distributing tenant data across multiple smaller databases. It uses a tenant identifier in the underlying schema to manage, monitor, and respond to the needs of each tenant. By allotting tenant data across several small databases instead of a single large database, Verb ensures that the system is more agile, cost-effective, consumes minimal resources, and is far less power-hungry.

In effect, instead of having multiple production instances of your B2B SaaS app, Verb creates one logical instance. It helps you to simultaneously serve multiple accounts that are made separable by tenant identifiers and a set of rules and permissions.

Keen to know more about the best practices in developing multi-tenant SaaS dashboards? Read this article by Oleg Fridman – the founder and CTO of Verb – on Coruzant.

Interested to know more about how Verb can help you grow and scale profitably? Visit https://verbdata.com/, or get in touch with us here to get started on your data visualization journey.

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