As we said above, in a multi-tenant environment, multiple customers share the same application, in the same operating environment, on the same hardware, and with the same storage mechanism and
database. This is how Salesforce and every other SaaS operator run. Every tenant is a customer/user who has common access and specific privileges in the software instance.
The database, however, is another matter. There are three ways to architect your database in a multi-tenant system.
A single, shared database schema
A schema is a layout for database tables that relate to each other. In the first approach, one database is used with tenant tables all linked to the database. The tables handle relations and version control or updates, such as handling two people attempting to manipulate the same table or data entry. This is the fastest way to operate, since only one database is being used, assuming it scales.
Single database, multiple schemas
Multiple schemas inside a single database is a popular method to have sub-databases, so you can divide up your data without having to set up multiple databases. Each schema is isolated from the others and operates differently, which can be useful in situations where different data has different regulations, like international data.
This takes the multi-schema approach one step further because now you have the data in multiple databases. Sales or customers can be divided up by region, for example. So the upside is you get the best isolation of data. Of course, that also adds to the complexity of management, maintenance, and scalability that would come with deploying multiple databases.
Multi-Tenant Architecture Examples
In a virtual system, one system may have 20 instances running 20 operating systems, each with its own application and database. In a multi-tenant architecture, all of the instances share the OS, app, and most importantly, the database.
Does this sound familiar? That’s not only how SaaS works but how Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) operate since both can be used to write highly scalable multitenant apps that are outward-facing, meaning customers and partners can use them.
That’s how 50 people from the same company can work on Salesforce CRM. Similarly, an SAP system is composed of a database backend and Web application servers that host Web services in a highly scalable manner. The Web services that make up the SaaS app are exposed to different customers via different domain names. Scaling is achieved by starting more services.
Most of the examples conform to these three ways to structure a multi-tenant application:
- URL-based SaaS. This is the easiest one to do since it uses a single domain and database. You would have specific URLs, like maindomain.com, subdomain2.maindomain.com, etc. Data management and security is handled at the application level. Some SaaS operates this way, especially those that put a Web app interface between the user and the database.
- Multi-tenant SaaS. This is more complex because of multiple databases and/or schemas, and restrictions are done at the database This is how many SaaS apps operate and often allow more direct interaction with the database.
Virtualization-based SaaS, like containers. This is the most complex setup because there is so much interaction between the containers as well as the apps and databases. That’s why there is so much emphasis on orchestrators like Docker and Kubernetes.