4 ms·
"As in a typical multi-tenant architecture, one database per customer." Maybe I've misunderstood what "multi-tenant" means for the last 5 years, but I always t
by callmeed 16y ago
"As in a typical multi-tenant architecture, one database per customer."
Maybe I've misunderstood what "multi-tenant" means for the last 5 years, but I always thought of it as "multiple customers on a single installation/instance and using a single database" ... as in, every customer has some sort of account model other models are scoped to the account.
I'm sure there are valid reasons for having a unique db per customer (we do it in one product) but it seems easier to maintain/backup a single one.
- snprbob86 16y agoIf your data is easily and completely partitioned by customer, it may make sense to do so. It's as easy a partitioning scheme you can come up with. It gives you the power to do staged roll outs and other flexibility in deployment, as well as security isolation that makes your life easier and some customers may prefer.