- Tags:: BBDDs
There are a few posts around there that try to defend the idea that, in the cloud and with tools you currently have, there should not be much pain in having tiny dedicated instances per user of your SaaS:
But loads of opinions against: citing mainly operational nightmares. I am wondering whether this still applies in 2020. Nobody answered my question however…
If doing multi-tenancy, there are again, a range of options, moving complexity from the operational side, to the software side:
- a database per customer (very close to the single-tenant case),
- schema per customer
- all customer sharing tables, all tables containing a tenant_id.
The schema per customer approach is interesting: its operational complexity is not big, and there are no big changes to code. However, there are several opinions claiming that this approach does not scale when customers in the 100s and it is best to go shared table when many customers.
- Our Multi-tenancy Journey with Postgres Schemas and Apartment
- PostgreSQL’s schemas for multi-tenant applications
- http://docsdrive.com/pdfs/ansinet/itj/2014/2489-2495.pdf
- Multi-Tenant Data Architecture
However, again, it is not really clear, but it seems the best option is to go with one tenant column on every table.