News for hackers. Stuff that matters.
Re:A database for 2022 by tptacek on Friday April 01, 2022 @10:08PM (#30885278)
Another comment on this thread tried to dunk on them, saying that they'd done this so many times before (JSON to etcd, etcd to sqlite) that they must be getting really good at it. That comment struck me as so close to understanding what they're doing right here, it was painful.
Re:A database for 2022 by jrockway on Saturday April 02, 2022 @12:00AM (#30885759)
Yeah. Maybe people are overestimating how expensive this kind of change is. We can all imagine being part of a larger org, where one day an All Hands appears on your calendar, and some exec you've never heard of proclaims the beginning of a 2 year multi-team database migration project. So now instead of making nifty software, you are just in 40 hours of meetings a week fighting over small details on this migration nobody wants to do, and everyone is miserable about it. Features stopped getting released, people leave the company, the weekly status meeting never makes the project seem anywhere near completion.

Say "switch databases on a successful project" and I bet people's minds go there. That is indeed expensive and painful, but if you have a small team, it's just being agile.

There is also the "punching up" / sour grapes aspect that can't be ignored. "I would have picked the right database from the start, but nobody's funding my crazy idea." Life just isn't fair, and HN is where you can vent, I guess.

Re:A database for 2022 by nrr on Saturday April 02, 2022 @12:58AM (#30885935)
I have the odd feeling that this kind of overestimation comes from the experience that folks tend to have in writing more traditional N-tier applications, especially post-Rails. A certain kind of database-first, ORM-first design philosophy really took hold after that, and it became somewhat common to see incredulity in response to telling someone that you weren't using something like MySQL or Postgres in production.

The kinds of projects that I more generally tend to see make these migrations successfully are the ones that design with in-memory data structures first and then sort out how best to persist that kind of thing to disk after their domain model has solidified a little bit.

Tailscale smells a lot like that to me.

Re:A database for 2022 by devmunchies on Saturday April 02, 2022 @01:51AM (#30886112)
When I used dynamic languages (Node.js and Ruby) I leaned on the database as the structural source of truth for types—it was the rigor a successful project needs.

But as I’ve been using only statically typed languages the last few years (on the backend), I’ve moved to designing the domains in the code, like you said.

Re:A database for 2022 by powera on Saturday April 02, 2022 @12:47PM (#30889608)
Yup.

When Tailscale migrates databases, it is a few engineers working for a few weeks solving problems that already exist.

When a company with 50k employees does it, it takes two years and only makes things worse.