6 ms·
Every B2B client who asked us how we handle multi-tenancy also asked how we ensure their data is erased at the end of the contract. Using a shared database with
by e1g 4y ago
Every B2B client who asked us how we handle multi-tenancy also asked how we ensure their data is erased at the end of the contract. Using a shared database with RLS means you have to go through all DB backups, delete individual rows for that tenant, then re-generate the backup. That’s a non-starter, so we opted for having one DB per tenant which also makes sharding, scaling, balancing, and handling data-residency challenges easier.
- axlee 4y agoIt makes BI work an absolute hellscape as well. Tradeoffs.
- mrtesthah 4y agoJust make the application collect the statistics you need. Put them into a separate shared DB or use one of the many existing off the shelf SaaS collection frameworks.
- hobs 4y agoAgree - performance on row level security (at least on SQL Server) is terrible, sharing by database is fairly easy.
- gervwyk 4y agoAlso second this, we even split our AWS org into an AWS account per tentant. Although, this will maybe be a problem if we have +100s of clients. But it makes onboarding and off-loading simple.
- HatchedLake721 4y agoIt depends on an annual contract value (ACV), doesn't it? You can't give an AWS account to every $99 p/m plan, but you can for enterprise $50-100k+ deals.
- gervwyk 4y agoYeah, that sums it up. I guess it means it can't be labelled as "multi-tenant" then..
- throw03172019 4y agoEach client is running on their own instances / load balancers?
- jamesfinlayson 4y agoIs account creation automated? I know there are some resources where you can only have one per region (I think you can only have one AWS::EC2::VPCEndpoint per... type and service per region) but I don't know if letting multiple tenants use the same VPC endpoint is a risk or not.
- X-Istence 4y agoYou can have an instance of a VPC Endpoint per VPC. You can have multiple VPC's all with the same VPC Endpoints. You just get billed for them ;-)
- jamesfinlayson 4y agoOh yes that makes complete sense - I'm living in a world where our internal AWS management team deploys our VPCs for us (one per account unless you have very special needs).
- bearjaws 4y agoWe usually write a "reasonable best effort" clause into our deletion, that it will 100% be deleted from production within 30 days and automatically fall out of backups 60 days from there. This also helps since we can't control our downstream vendors such as Twilio, AWS SES, etc, who all have their own legal obligations and time frames. Even for large health systems they have been okay with it.
- jerryjerryjerry 4y agoI think TTL feature provided by some DB vendors are actually orthogonal to multi tendency, where the former deals with life cycles policy of data but the original problem to delete the data of certain user is more related to privacy policy of data, though overlap may exists.
- SahAssar 4y agoI think the way to handle this (based on how many companies handle GDPR compliance) is to not keep backups older than X months (usually 3 months) and have a clause that all data past that time is deleted.
- brightball 4y agoI filled out a ton of enterprise questionnaires on this stuff before and we just told people that it would be deleted when the backups expired after X days because we didn't have the capability to delete specific rows from our backups. Nobody ever argued. There's not a single customer I've ever run across who's going to halt a contract because you can't purge their data from your backups fast enough. They're signing up because of what you offer, not the termination clause.
- coenhyde 4y agoi did the same with the same results
- mikeodds 4y agothirded
- wahnfrieden 4y agosame. but! it’s a liability nonetheless, go talk with legal etc
- voberoi 4y agoThis is the way -- also never had an issue across US healthcare and enterprise SaaS.
- e1g 4y agoA recent example from the other side: a client contacts me and says they will have to exit from our existing contract unless we can update our (AWS) infrastructure to use their (AWS) encryption keys for servers and databases handling their tenancy. In Enterprise, some tenants are very opinionated about what cloud you use and how their data lives/flows within it. I run all our infosec, including SOC2 & ISO27001 programs, and I know that using their encryption keys is nothing but security theater. But with $500k p.a. on the line, I also know when it's showtime.
- brightball 4y ago
- jquery_dev 4y agoHow do you manage your backend in this case? Do you have an insurance of backend for each customer or do you allow backend to make connections to all the DBs. I'm interested in doing similar and wondering about the best way to handle the routing between the databases from a single backend.
- mason55 4y agoIt really depends on your requirements, both functional and cost. Having a full stack per customer can be great for a lot of reasons. It's probably the safest because you never have to worry about something getting messed up in the code and creating cross-customer access. Once you're sure the environment is set up correctly you can sleep well at night. You also don't have to worry about one customer doing something to impact the performance of other environments (unless you're using shared infra, like putting all your DBs on a single cluster). And it can make maintenance easier, for example you can data migrations can start with small and/or less important customers for practice. It also can give you more flexibility if you need to make special snowflakes (i.e. some big customer wants weird IP whitelisting rules that can't work with your normal env setup). Downsides are that it's probably more expensive and more work. Even if your infra spin up is totally automated, you still need to keep track of all the environments, you still need to keep your Infrastructure-as-Code (e.g. your terraform scripts) up to date, more can go wrong when you make changes, there's more chance for environments to drift. So, in short, separate stacks usually means more safety & simpler application architecture in exchange for more cost and more effort to manage the fleet.
- Dave3of5 4y ago> we opted for having one DB per tenant which also makes sharding, scaling, balancing, and handling data-residency challenges easier When you say 1 DB I suspect you mean you have a single DB Server and multiple DB's on that server. Then I don't think this really solves the data-residency problem as the clients data is just in a different DB but still on the same instance. It makes other problems for you as well for example you now have 2 DB's to run maintenance, upgrades, data migrations on. Current company uses a similar model for multiple types of systems and it makes upgrading the software very difficult. It also makes scaling more difficult as instead of having a single DB cluster that you can tweek for everyone you'll need to tweek each cluster individually depending on the tenants that are on those clusters. You also have a practical limit to how many DB's you can have on any physical instance so your load balancing will become very tricky. There are other problems it causes like federation which Enterprise Customers often want.
- spiffytech 4y ago> we opted for having one DB per tenant which also makes sharding, scaling, balancing, and handling data-residency challenges easier I'm surprised this simplified balancing for you. When I worked somewhere with per-customer DBs, we had constant problems with rebalancing load. Some customers grew too big for where we put them, some nodes usually performed fine until the wrong subset of customers ran batch jobs simultaneously, etc.
- BeefWellington 4y agoOne DB (or perhaps schema, depending on DBMS) per tenant is the way to go IMO. It simplifies so much of your work, from DR to deletion to scaling.