I've read that one big disadvantage of the database per tenant model in multi-tenant applications is the extra resource cost of having many (potentially thousands or tens of thousands) databases online at the same time. What factors affect the number of tenant DB's I can have online at the same time?

Considering that the total amount of data will be (mostly) the same between the DB per tenant and single DB architecture why would a DB per tenant architecture reach the limits faster than a single DB?

I'm using MS SQL Server 2016 but I would be interested to hear answers for other DBMS's as well.

  • 1
    The limitations will largely depend on your hardware and workload. You could have a single tenant with one user and hit limitations with inadequate hardware. Feb 12, 2017 at 12:30
  • This is like asking how many trips to the grocery store will I be able to make with a 1982 Oldsmobile... Feb 12, 2017 at 13:30
  • @AaronBertrand Why? I'm asking what about the multiple DB approach makes it more likely to have resource issues. The total amount of data will be (mostly) the same with either a separate DB or single DB approach so why is there a bigger performance hit with separate DB? Feb 12, 2017 at 13:33
  • You asked how many DBs before you run into resource limitations. Nobody can answer this - there is no magic number like 200 or 37 or 552 - it all depends on far too many factors. There have been discussions in the past that are related that you might find useful (e.g. this one for SQL Server, and this one for MySQL), but none of them will answer the actual question you've asked. Feb 12, 2017 at 13:37
  • @AaronBertrand I'm not asking for an absolute number. I want to know what the factors which contribute to the number are and why a multiple DB architecture reaches the threshold faster than a single DB one. Feb 12, 2017 at 13:48


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.