Azure: should I use Single Tenant or Multi Tenant?
Introduction
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.
Done. Let’s get technical now…
I want to write this post because I’ve lately replied to a question on dba.stackexchange.com 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:
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… 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 dba.stackexchange.com one user suggested me to add to the list of Tenant options Azure Table Storage which is actually the database behind https://haveibeenpwned.com/ .
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 https://haveibeenpwned.com/ 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 https://customers.microsoft.com .
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:
Or not:
