[randlet]

> 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.

[e1g]

Same setup for us, as this is the only option for B2B/enterprise products you have contractual obligations to delete all tenant data at the end of the term.

Additional benefits: easy to support customer-managed encryption keys and can give their BI people direct access.