Building a Multi-Tenant Application

Multi-tenancy is the capability to address the needs of modern enterprise applications as well as Software as a Service (SaaS) applications to reach out to multiple customers, while enforcing an effective isolation of data, configurations, and end-users.

This approach allows a single Application Server and Database Server to provide each customer with his own isolated set of computing resources.

From the customer point of view it looks like you have your own application, when in fact there is a single application that allows for some degree of customization between each customer.

Benefits of Using Multi-tenancy

Designing applications using a Multi-tenant architecture has several benefits:

Decreases infrastructure operation costs, since there is only one application deployed in the server.

Enforces a strict security policy for data, end-users, sessions, and processes.
Simplifies the application development and maintenance processes, since there is a single code base to maintain.


Many companies need to create a website that can be used by many customers or parties independently of each other. Each customer has their own data and never should data leak between customers. An example is the Constant Contact email marketing site. Each account has its own email lists, custom templates, history of emails sent, user list, etc. Another example is Google Docs. You can manage your own set of documents, but no other user should accidentally get your documents. This is a multi-tenant system and it has many benefits. Primarily it allows you to maintain a single website and single database for all customers or accounts. In the past some single tenant architectures required a new installation for each customer. This is not scalable and is only viable with a large dedicated IT department.

The ability to create and easily maintain a multi-tenant application saves development time, IT resources, and removes tenant data bleed. The nHydrate modeler allows you to build on top of this architecture using Entity Framework Core. EF Core is a great product but it has no out-of-the-box way to create a multi-tenant model. When a code entity is created and mapped to a database table, the generated query is simply a “Select All” query. A developer can add a Where statement of course but there is no automatic way to segment data based on account.

Each entity in the modeler has a property, IsTenant, that marks a table as tenant based. This functionality is transparent to the developer. No query or LINQ statement can be constructed that will accidently pull information from multiple tenants. Only a single tenant’s data can be accessed from a database connection. Even if no Where statement is provided, there can never be cross tenant bleed.

Not all tables need to be marked as a tenant table. Static data is an example that need not be segmented. Actually any table that will require cross tenant lookup cannot be marked this way. An example might be login history that an admin panel views. Since an admin can see across tenants, a table storing this information cannot be a tenant table. Tables that are only accessed through a tenant table might not need this functionality either.

An example of this would be a dependent table. Say each account has a Project table that stored the customers projects. There is also a ProjectItem table that stores some sort of dependent data. If the application only accesses the ProjectItem table based on the foreign key from Project, then there might not be a need mark ProjectItem as tenant since the application always looks up the ProjectId through the Project tenant table. Every situation is unique, so this really depends on the defined business rules.

Examples and Further Reading

There is a sample project that demonstrates how to create a multi-tenant API on Github using SQL Server. This will also work in Postgres with minimal changes. . The nHydrate WIKI has some further explanation and sample code as well.

%d bloggers like this: