3 ms·

I think what the author misses is that SQLite's choices make a lot of sense in a world where working with the DB is super easy and you can move a lot of the com

I think what the author misses is that SQLite's choices make a lot of sense in a world where working with the DB is super easy and you can move a lot of the complexity to the code around it. With traditional databases it used to be the case that you manage everything in the DB, because it's expensive to call it, and because you don't always know who's going to call it, but that's clearly not a typical scenario for SQLite.

sgbeal 2y ago
> I think what the author misses is that SQLite's choices make a lot of sense in a world where working with the DB is super easy and you can move a lot of the complexity to the code around it. One concrete example of that is sqlite's own source control system, the Fossil SCM. Within Fossil, sqlite does _lots_ of the heavy lifting, replacing tens of thousands of lines of C code[^1]. Richard Hipp (of sqlite fame) recently mused that sqlite takes on at least the following distinct database roles in that project: - Document database (how SCM records are natively stored[^2]). - Graph database (queries which extract the lineages of projects' artifacts from directed acyclic graphs[^3]). - Key-value store for config data of arbitrary types (all in the same table). The first two can be done with any SQL db, but the latter requires sqlite's particular flexibility. Never once (literally never once) in the development of fossil has that flexibility caused us (==its many contributors) any grief. [^1]: as a fossil contributor since 2008, i can say with complete confidence that that is no exaggeration. [^2]: <https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...> [^3]: <https://core.tcl-lang.org/tcl/timeline?c=2024-06-30 https://core.tcl-lang.org/tcl/timeline?c=2024-06-30> is a good example

sgbeal 2y ago

> I think what the author misses is that SQLite's choices make a lot of sense in a world where working with the DB is super easy and you can move a lot of the complexity to the code around it. One concrete example of that is sqlite's own source control system, the Fossil SCM. Within Fossil, sqlite does _lots_ of the heavy lifting, replacing tens of thousands of lines of C code[^1]. Richard Hipp (of sqlite fame) recently mused that sqlite takes on at least the following distinct database roles in that project: - Document database (how SCM records are natively stored[^2]). - Graph database (queries which extract the lineages of projects' artifacts from directed acyclic graphs[^3]). - Key-value store for config data of arbitrary types (all in the same table). The first two can be done with any SQL db, but the latter requires sqlite's particular flexibility. Never once (literally never once) in the development of fossil has that flexibility caused us (==its many contributors) any grief. [^1]: as a fossil contributor since 2008, i can say with complete confidence that that is no exaggeration. [^2]: <https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...> [^3]: <https://core.tcl-lang.org/tcl/timeline?c=2024-06-30 https://core.tcl-lang.org/tcl/timeline?c=2024-06-30> is a good example