Azure: should I use Single Tenant or Multi Tenant?


Holy moly! I’m been so busy skiing lately that I’ve completely forgot to write on my blog.

I open up my post list and I find 11 draft… 😱

Let’s start from something  easy that I really like: database architectural decision. No, really, this time we are not going to discuss if your database diagram should have the shape of a star, a snowflake or an heart; this time I promise I’m going to help you out with a single question you should ask yourself:

Can you name your customers?

That’s it. That was the question you should have ask yourself.

  • If you can tell the name of your customers that means you can dedicate a database to them, therefore –> use Single Tenant.
  • If you cannot name your customers because your application has a number of users that come and go… well users are your customers, therefore –> use Multi Tenant.

Or just go to the Sales department and ask “Have we spoke with each one of our customers? Do we have their phone numbers in our CRM?“.

That’s indeed an easy way too to see if you have customers or user. Because everything really boils down to that: understand if you have customers or users.

Single Tenant is for customers like…Multi Tenant is for users like…
Hospitals: you deliver an application that helps manage hospitals’ patients along with their operation date, drugs, accounting, etc…Taxis: you deliver an application that allows users to register themself as drivers and provide rides (Uber)
Retails: you are delivering an application that provides Point Of Sales for chains like Walmart, Tesco, IKEA, etc…Hospitality: you deliver an application that allows users to rent their home/flat to other users (AirBnB)
Cinemas: you are delivering an application that provides solutions for cinema chainsE-commerce: you build a website that allows users to sell their items (eBay)

Done. Let’s get technical now…

I want to write this post because I’ve lately replied to a question on and while for me this is quite simple to understand I see there are a lots of doubts around this architectural choice.

If we take Azure as the landing Cloud of choice we can easily divide the products this way:

For Single Tenant For Multi Tenant
Azure SQL Database: When possible is my first choice. There are a bunch of options for Azure SQL Database and I’m not going to enumerate them because by the time I’ve finished they will already have changedAzure Hyperscale: Like Azure SQL Database but on steroids. Is actually the most priced and muscley Azure SQL Database.
Azure SQL Edge: tailored for IoT streaming data in real time. At least this is what they said... Cosmos DB: geo-replicated NoSQL database for modern app development.

Mind you, Brent Ozar lately approached this topic and said (watch minute 6:00):

“[…]if you put every client inside their own database it’s really easy to spread databases over all kind of places  […] if you put everything in one database it’s easier development but it will be harder performance tuning later. It will come back to hunt you as the size grows”

I could not agree more.

And there is also one other thing you have to keep in mind.

What if your product of choice is going to be retired?

I’ve dedicated my last posts to Dynamic Data Masking.
One of the features that I would have loved to use was Static Data Masking but the product was in “Preview” and you know what preview means for Microsoft? It means you are the guinea pig. The product has been removed and all documentation buried in the desert. Only a few 3rd party sites still preserves some screenshots and I’m going to save one for future generations to come:

SQL Server Static Data Masking
SQL Server Static Data Masking… just to prove that I wasn’t crazy: that feature was present once on SSMS

If you think this is a unique event think twice: Microsoft lately retired SQL Server Big Data Cluster. That was beefy. That’s like trying to hide your dog under the doormat.

Even in the comments of my answer on one user suggested me to add to the list of Tenant options Azure Table Storage which is actually the database behind .

I didn’t know the project and I have only dived into the surface of it: it doesn’t look like something you can use on production. It’s something for a side project or for the project you develop at home late at night but I would not bet to put that in production.

And actually started as side project.

So the next question is:

How can I determine if a product is going to last in the long term?

I’m going to give you the crystal ball that will tell you that: use . 

At that address you will find customers stories and thanks to the auto complete search bar you can find if a product has been adopted:

Azure SQL DatabaseOr not:

Azure Hyperscale


Leave a Reply

You have to agree to the comment policy.