MNW #038: Multi-Tenant Applications With EF Core

Read time: 4 minutes

A big thank you to our sponsors who keep this newsletter free to the reader:

Today's issue is sponsored by Refactoring. Refactoring is a weekly newsletter about making great software and working well with humans. It is read every week by 35,000+ developers, managers and leaders at companies like Google, Meta, and Amazon. Check it out here.

And by Jam. Reduce time spent on bug reporting with Jam by 60-80%. Auto-capture dev logs & network requests in one link, access Instant Replays for hard-to-repro bugs and integrate with Jira, Slack & more. Free Team Tier for the rest of 2023. Get Jam now.

Most software applications today are built around the concept of multi-tenancy.

One application serves multiple customers, while keeping their data isolated.

You can approach multi-tenancy in two ways:

Single database and logical isolation of tenants
Multiple databases and physical isolation of tenants

Which option you decide to use will depend mostly on your requirements. Some industries like healthcare require a high degree of data isolation, and using a database per tenant is a must.

So how are we going to implement multi-tenancy support with EF Core?

We can use Query Filters to apply a tenant filter to all database queries.

Implement it once, and you can almost forget about it.

Let's see what are some of the problems we need to solve.

How To Use EF Core Query Filters

If you want an in-depth dive into Query filters, take a look at the newsletter issue where I talked about using query filters with EF Core.

Here's a quick refresher on Query filters:

Configure the query filter by calling HasQueryFilter for your entity
EF will apply it to all queries for that entity
You can turn it off with IgnoreQueryFilters
Only one query filter per entity is allowed

And here's a simple example:

All queries to the Order table will include an IsDeleted = FALSE condition.

Single Database Multi-Tenancy With EF Core

You will need two things to implement multi-tenancy on a single database:

A way to know who the current tenant is
A way to filter the data for that tenant only

The typical approach for multi-tenancy on a single database is having a TenantId column in your tables. And then filtering on that column when querying the database.

You can use the Query filters feature in EF Core to apply a global filter for some entity.

Inside of the OnModelCreating method we configure the query filter on the Order entity:

We're using the TenantProvider class to get the current tenant value.

Here's what the TenantProvider implementation looks like:

The TenantId is coming from the HTTP request header in this example.

A few other options to get the TenantId are:

Query string - api/orders?tenantId=example-tenant-id
JWT Claim
API Key

If you want a more secure implementation you should go with JWT Claims or API Keys to provide the TenantId value.

Separate Databases Multi-Tenancy With EF Core

What if we want to isolate each tenant to a separate database?

Here are the changes we need to make:

Applying different connection string per tenant
Resolving the connection string for each tenant somehow

You can't use Query filters here, since we are working with different databases.

So you will need to store the tenant information and connection strings somewhere.

A simple example would be store them in the application settings:

You can then register an IOptions instance with a list of Tenant objects.

And we need to slightly modify the TenantProvider class to return a connection string for the current tenant:

And the last part is registering your DbContext to dynamically resolve the connection string for the current tenant.

On every request, we create a new OrdersDbContext and connect to the appropriate database for that tenant.

You should definitely consider storing the tenant connection strings in a secure place like Azure Key Vault.

Closing Thoughts

I hope you now have a better understanding of how to build a multi-tenant system with EF Core.

I showed you the bare bones implementation, which you can improve to make it more robust and secure.

Building multi-tenant systems isn't easy, but when you understand the basic principles it shouldn't be too difficult either.

That's all for this week.

See you next Saturday.

Whenever you're ready, there are 2 ways I can help you 🎁

If you're looking to join a community of like-minded engineers or you want to access all of the source code that I use in my YouTube videos, you can do that by becoming a Patron. Join 680+ engineers here.
Promote yourself to 20,000+ subscribers by sponsoring this newsletter (booked out 2 months)

You received this email because you subscribed to our list. You can unsubscribe at any time.

Dragise Cvetkovica 2, Niš, 18000, Serbia

MNW #038: Multi-Tenant Applications With EF Core

MNW #038: Multi-Tenant Applications With EF Core

How To Use EF Core Query Filters

Single Database Multi-Tenancy With EF Core

Separate Databases Multi-Tenancy With EF Core

Closing Thoughts

Older messages

MNW #037: Visualize Your Software Architecture With The C4 Model

MNW #036: Enforcing Software Architecture Rules With Architecture Tests

MNW #035: Health Checks In ASP.NET Core For Monitoring Your Applications

MNW #034: Idempotent Consumer - Handling Duplicate Messages

MNW #033: EF Core Raw SQL Queries

You Might Also Like

Import AI 399: 1,000 samples to make a reasoning model; DeepSeek proliferation; Apple's self-driving car simulator

Defining Your Paranoia Level: Navigating Change Without the Overkill

5 ways AI can help with taxes 🪄

Recurring Automations + Secret Updates

The First Provable AI-Proof Game: Introducing Butterfly Wings 4

GCP Newsletter #437

Charted | The 1%'s Share of U.S. Wealth Over Time (1989-2024) 💰

The Great Social Media Diaspora & Tapestry is here

Daily Coding Problem: Problem #1689 [Medium]

📧 Stop Conflating CQRS and MediatR