> 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 SQLi

> 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.