Is a multi-tenant database:
- A DB server that has a different (identical) database/schema for each customer/tenant?; or
- A DB server that has a database/schema where customers/tenants share records inside of the same tables?
For instance, under Option #1 above, I might have a MySQL server at, say,
mydb01.example.com, and it might have a
customer1 database inside of it. This
customer1 database might have, say, 10 tables that power my application for that particular customer (Customer #1). It might also have a
customer2 database with the exact same 10 tables in it, but only containing data for Customer #2. It might have a
customer3 database, a
customer4 database, and so on.
In Option #2 above, there would only be a single database/schema, say,
myapp_db, again with 10 tables in it (same ones as above). But here, the data for all the customers exists inside those 10 tables, and they therefore "share" the tables. And at the application layer, logic and security control which customers have access to which records in those 10 tables, and great care is taken to ensure that Customer #1 never logs into the app and sees Customer #3's data, etc.
Which of these paradigms constitutes a traditional "multi-tenant" DB? And if neither, then can someone provide me an example (using the scenarios described above) of what a multi-tenant DB is?