When you’re designing the back end of a database, people will have all sorts of ideas.
Normalization, partitioning, referential integrity, and, usually, trying to figure out what to do when you have more than one client.
If your application is user-focused (like Stack Overflow), you don’t have to struggle too much with the idea of isolation. But when your application is geared more towards supporting multiple entities that have one or more users, things change. Sort of like how Stack Overflow manages all the other Stack Network sites.
Were you to ask me which model I prefer, it would be every tenant getting their own database. Your other options are:
- Everyone all mixed in together like gen-pop
- Using separate schemas inside a single database
Definitely read what Erik has to say. My prior job was a hybrid multi-tenant environment: for the main transactional database, there were several dozen SQL Server instances. Each instance had anywhere from one to a few dozen copies of the transactional database, and each database hosted one or more customers’ data. There’s not a lot of tooling out there to support that kind of strategy, so we had to build a lot of it in-house. But that said, it did work out reasonably well without having hundreds or thousands of databases on a single instance.