> is this how multi-tenancy is typically implemented (a per-tenant-database)? There's a few different approaches and deciding which to use can be tough. When

> is this how multi-tenancy is typically implemented (a per-tenant-database)? There's a few different approaches and deciding which to use can be tough. When I was adapting a formerly single tenant Django application to a multi-tenant solution, I went for a "db-per-customer" (with many databases on a single db server) for a few main reasons: 1) Allows you to backup and restore databases on a per customer basis. 2) Helps with IT reviews if you can say "your data exists in its own DB and is not co-mingled with other customers data" 3) Implementation seemed like it was going to be simpler, especially for adapting an existing single tenant application to a multi-tenant one. 4) Makes it easy to migrate existing single tenant-db's to the multi-tenant app. The main drawback for us I would say is that it makes managing database migrations/schema changes a bit more challenging since you now need to update N db's every time there's a schema change. This was not super difficult though. Overall I am very happy we decided to go with a multi-db multi-tenancy solution.