2 ms·
My personal preference for a single multi-tenanted schema as opposed to 2000+ schemas is: Unless you require per customer customisations (which is a fast way to
by joncampbelldev 10y ago
My personal preference for a single multi-tenanted schema as opposed to 2000+ schemas is:
Unless you require per customer customisations (which is a fast way to ensure you have an upper limit on the number of customers you can support) there is no need to duplicate. Use a single schema where every table with per-customer data has a tenant id column.
Most decent RDBMS have a good way to ensure isolated locks across tenant ids e.g. MySQL partitions.
- leesalminen 10y agoUnderstood. Currently, I manage several hundred logical databases for a B2B SaaS product. This has the potential to grow to several thousand over the course of years. My customers enjoy that (arbitrary) piece of mind that their data is logically separated from all else. I enjoy not having to remember to include a tenant_id clause. Our traffic pattern is quite steady per hour of day and per customer. That, plus using RDS for horizontal scaling (fixed # of logical DBs per host) allowed us to take this route. I suppose the decision is a matter of circumstance and preference, but I don't think this is necessarily "wrong" to do.
- beachstartup 10y agoit's going to work fine until it doesn't. that's not going to be a good day. smart people can rationalize anything.