4 ms·

The cost of complication is high. They're optimizing for simplicity. Both for low friction development and easy operation. sqlite is amazingly simple for local

by mrkurt 5y ago

The cost of complication is high. They're optimizing for simplicity. Both for low friction development and easy operation. sqlite is amazingly simple for local dev. Probably even simpler than a json file. High availability Postgres is complex to operate (you need a whole separate strongly consistent data store to coordinate it). Cassandra is also very complex. sqlite is, again, simpler. Litestream makes sqlite plausible for production.

cogman10 5y ago
> sqlite is amazingly simple for local dev You are buying simpler local dev with a more complicated and error prone production. > High availability Postgres is complex to operate High available SQLite is complicated. More complicated by the fact that SQLite wasn't designed at all around the notion of being a multi-tenant database system. Instead, you've got to bolt on solutions to fix the fact that you chose SQLite. Containers make local dev with postgres or other db technologies pretty slick. I have a hard time buying the "oh no, but then we need to run docker" because docker containers have added benefits often simplifying local dev (All your dev tools defined in the docker file. Done, new dev installs docker and moves from there). > sqlite is, again, simpler. Litestream makes sqlite plausible for production. SQLite is a fantastic tool, when it's used in the right location. A backend database is not the right location for SQLite. Litestream may make it "plausible" but it certainly doesn't make it a sane choice.
- tptacek 5y ago
  They don't have a multi-tenant database problem! This is the second weird thing you've said about this design (the other was that they'd need to run Jepson simulations for it). They're not a database hosting provider; they're the single producer and the single consumer of their database. They have a single writing leader, and read-only replicas. That's how Litestream works; it's the only way it works.
- yawaramin 5y ago
  > You are buying simpler local dev with a more complicated and error prone production. How so? Any evidence for that? > More complicated by the fact that SQLite wasn't designed at all around the notion of being a multi-tenant database system. Neither was Tailscale, that's why the engineers decided they were a good fit. But I'm sure you know more about it than they do. > Containers make local dev with postgres or other db technologies pretty slick. No they don't. Dockerizing everything for local dev bogs you down to Docker's added latency for every operation, this is not even getting into the latencies added by having to periodically `docker pull`, `build` images, provision the disk space for the images, and maintain all that infrastructure over time. Compared to that, an SQLite database is basically nothing. > All your dev tools defined in the docker file. Done, new dev installs docker and moves from there Docker is not a good way to do local dev, overall. The entire point of local dev is speed of iteration. If you need a usable test environment, set one up in UAT. > A backend database is not the right location for SQLite. The SQLite team actually disagrees with you on this: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html > SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites)....Systems designers report success using SQLite as a data store on server applications running in the datacenter, or in other words, using SQLite as the underlying storage engine for an application-specific database server. But again, I'm sure you know better than them.

by mrkurt 5y ago

cogman10 5y ago

> sqlite is amazingly simple for local dev You are buying simpler local dev with a more complicated and error prone production. > High availability Postgres is complex to operate High available SQLite is complicated. More complicated by the fact that SQLite wasn't designed at all around the notion of being a multi-tenant database system. Instead, you've got to bolt on solutions to fix the fact that you chose SQLite. Containers make local dev with postgres or other db technologies pretty slick. I have a hard time buying the "oh no, but then we need to run docker" because docker containers have added benefits often simplifying local dev (All your dev tools defined in the docker file. Done, new dev installs docker and moves from there). > sqlite is, again, simpler. Litestream makes sqlite plausible for production. SQLite is a fantastic tool, when it's used in the right location. A backend database is not the right location for SQLite. Litestream may make it "plausible" but it certainly doesn't make it a sane choice.

tptacek 5y ago
They don't have a multi-tenant database problem! This is the second weird thing you've said about this design (the other was that they'd need to run Jepson simulations for it). They're not a database hosting provider; they're the single producer and the single consumer of their database. They have a single writing leader, and read-only replicas. That's how Litestream works; it's the only way it works.
yawaramin 5y ago
> You are buying simpler local dev with a more complicated and error prone production. How so? Any evidence for that? > More complicated by the fact that SQLite wasn't designed at all around the notion of being a multi-tenant database system. Neither was Tailscale, that's why the engineers decided they were a good fit. But I'm sure you know more about it than they do. > Containers make local dev with postgres or other db technologies pretty slick. No they don't. Dockerizing everything for local dev bogs you down to Docker's added latency for every operation, this is not even getting into the latencies added by having to periodically `docker pull`, `build` images, provision the disk space for the images, and maintain all that infrastructure over time. Compared to that, an SQLite database is basically nothing. > All your dev tools defined in the docker file. Done, new dev installs docker and moves from there Docker is not a good way to do local dev, overall. The entire point of local dev is speed of iteration. If you need a usable test environment, set one up in UAT. > A backend database is not the right location for SQLite. The SQLite team actually disagrees with you on this: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html > SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites)....Systems designers report success using SQLite as a data store on server applications running in the datacenter, or in other words, using SQLite as the underlying storage engine for an application-specific database server. But again, I'm sure you know better than them.