3 ms·
I would say most people don't need a database per tenant and that is definitely not the norm. There are specific cases that you would need to negate the drawbac
by Lord_Zero 1y ago
I would say most people don't need a database per tenant and that is definitely not the norm. There are specific cases that you would need to negate the drawbacks such as migrations and schema drift.
I think the lack of gems/libraries/patterns is proof of this. Just because you can doesn't mean you should.
Not saying there's no reason to ever do it, proceed with caution and know for a fact you need db per tenant.
- thethimble 1y agoSeems like it’s actually really convenient as independent customer data ends up being nicely isolated. Deleting churned customer data is as trivial as deleting their database. > I think lack of gems/libraries/patterns is proof of this This would effectively disqualify any new pattern from emerging. There have been many new patterns that have challenged the consensus that ended up becoming dominant.
- Lord_Zero 1y agoThis is more proof of what I am saying. The urge to have something "nicely isolated" really needs to come with a checklist of why you need this, otherwise this comes off as a developer's desire for cleanliness regardless of major drawbacks. Running some `DELETE FROM x WHERE TenantId = 1` is not a huge deal. And yes I see your point about new patterns, but were talking about multi-tenancy not some new AI thing. Ss someone with decades of experience I have found that if I go to implement [insert common pattern] and there is 0 libraries one way and 20 libraries the other way I need to check myself and determine if I am swimming against the current for little upside.