Source: Microsoft Azure

With the growing advancements in the field of technology, dependence on the database has also increased by several folds. Behind every streamlined software system, there is a highly efficient database that yields optimum performance. 

One cannot deny that there has been a dramatic improvement in the way database architecture was defined to cope up with the growing demand for high performance. 

At the same time, along with the optimum performance, another aspect which matters is the cost efficiency. Often, the companies do not have big budgets to buy their own individual hardware and they tend to share or rent hardware and software resources as per their requirements. 

This is possible with the advent of cloud technologies, where the data of the company gets stored on the cloud. It not only makes the data accessible to different parties located across various locations, but it also saves the costs for the company.

To optimise the use of database resources that are shared among different parties, the idea of multi-tenant database architecture emerged as one of the most successful ones.

Let us begin with what a Multi-tenant database architecture is, the factors that help in determining the right architecture and how it works to get an in-depth idea of multi-tenant architecture.

What is a multi-tenant database architecture?

Multi-tenant database architecture is a provision in which a single database is used to store data for different parties by ensuring that the privacy and security of each one of them are duly maintained.

This is done by choosing the right tenancy model to map the storage to each of the tenants as per the tenant identifiers, to meet their database requirements. Azure SQL Database is one of the best choices for designing a multi-tenant database architecture for SaaS platforms.

The database pattern enables you to store more than one tenants in each shard. And thus one can optimize the database by having them shared between multiple tenants. 

Source: Microsoft Docs

How does it work?

The multi-tenant database such as Azure SQL Database supports creating multiple schemas within a single database. These schemas are isolated from one another and are not tied with each other, thus they practice independently within the common database. 

The tenant table that has the tenant identifiers for all the tenants are placed in the shared schema, which is public in nature. 

When an entry for a new tenant would be created in the tenant table, a new schema for it would be formed. This way any scoped query for that particular tenant shall be directed to the respective tenant schema.

It helps in optimizing the database resource, where a single database is shared to keep separate data for different tenants, where each of them are isolated and do not overlap, without the need of additional scope filters for each of the tenants.

Source: https://interworks.com.mk/multi-tenant-architecture-using-java-spring-and-hibernate/

Factors that help to design the right multi-tenant database architecture

The multi-tenant database is built mainly to address the database needs of the various tenants that share the common database resources, and thus the DBA needs to consider these to deliver an optimized multi-tenant architecture. Here are some of these factors:

• Scalability of the database

This includes several other factors that determine the scalability of the required multi-tenant database architecture such as 

• the number of tenants that are going to share the database resources, 
• the storage that each of these tenants would require,
• the aggregate storage of the database
• overall estimations of the workload 

• Tenant isolation

Whether the tenant’s workload overlaps or impacts each other in terms of individual performance. In such a case, where the tenants impact each other, one needs to practice tenant isolation. 

• Database costs per tenant

This is an important factor while designing the multi-tenant database architecture to make it optimal in terms of business and economic interests. Depending upon the per-tenant costs or budget estimates, the costs of the overall database are determined.

• Development complexities

The complexities of the development process such as changes to the schema or the changes to queries based on the requirements of the pattern. These complexities play a major role in designing the architecture so as to ensure each of these are well accommodated without hampering the overall performance.

• Operational complexities

It is important to consider the operational complexities that would surface later during active operations while designing the architecture to make it optimized for high performance. 

These complexities include monitoring and managing the performance, schema management, restoring a tenant and disaster recovery.

• Customizability of schemas

While designing the architecture, the customizability of the schemas happens to be an important aspect that makes the database more flexible and seamless in terms of performance. It would include both tenant-specific and tenant class-specific customizability of the schemas.

Having considering these factors and using them to plan the design of the multi-tenant database architecture, ensures that the database performs well on all the fronts delivering seamless and streamlined services to all the tenants.

Thinking Beyond

All of the above contribute together in building a multi-tenant database architecture that serves its purpose to a greater extent with optimization. 

But what remains a noteworthy point is the way how each of them is leveraged optimally to deliver the best possible architecture that is capable of meeting all the business requirements.

This is possible only when a diligent DBA with a vast industry experience works on formulating the architecture. It is because having a thorough experience lets the DBA not only consider these factors but also enables them to come out with the best possible solutions by foreseeing the future prospects. 

Thus, it is essential to make the right choice when it comes to choosing the DBA for an optimised performance of your database.

If you are planning to design the architecture of your multi-tenant enterprise database, then you are in the right place.

I am Eric Vanier, a DBA consultant with an experience of nearly two decades working with a wide range of enterprises, which includes several Fortune 500 companies, helping them optimize their enterprise database.

Feel free to get in touch if you are looking forward to optimizing your database.