3 ms·
Not a downside to me. Each team maintains their own DB and pays for their own choices. In the kitchen sink model all teams are tied together for performance an
by Scubabear68 3y ago
Not a downside to me. Each team maintains their own DB and pays for their own choices.
In the kitchen sink model all teams are tied together for performance and scalability, and some bad apple applications can ruin the party for everyone.
Seen this countless times doing due diligence on startups. The universal kitchen sink DB is almost always one of the major tech debt items.
- sgarland 3y agoI’m a DBRE, which means it’s somehow always my fault until proven otherwise. And even then, it’s usually on me to work around the insane schema dreamt up by the devs. Multi-tenant DBs can work fine as long as every app has its own users, everyone goes through a connection pooler / load balancer, and every user has rate limits. You want to write shitty queries that time out? Not my problem. Your GraphQL BFF bullshit is trying to make 10,000 QPS? Nope, sorry, try again later. EDIT: I say “not my problem,” but as mentioned, it inevitably becomes my problem. Because “just unblock them so the site is functional” is far more attractive to the C-Suite than “slow down velocity to ensure the dev teams are doing things right.”
- CoolCold 3y agoYou forgot the modern mantra - dev team is always right!
- Scubabear68 3y agoI agree. My gripe was everybody in the same schema with a global “app” user.
- dalyons 3y agoOr, you just avoid doing multi tenet from the start and none of those become your problem to unblock. What’s the downside?
- sgarland 3y agoDone that as well; it still becomes my problem because teams without RDBMS knowledge eventually break it, and… then I get paged. Full Stack is a lie, and the sooner companies accept that and allow people to specialize again, and to pay for the extra headcount, the better off everyone will be.
- dalyons 3y agoI disagree I guess. Multiple companies I’ve worked at have broken up their shared db into many dbs that individual teams own the operations of, and it works just fine. At significant scale in traffic and # of eng. No central dbas needed - smaller databases require much less skills to manage. The teams that own them learn enough.
- maccard 3y ago> Not a downside to me. Each team maintains their own DB and pays for their own choices. This is how you end up with the infamous "jira and confluence have two different markdown flavors" issue.