I quickly read through the `sqlite-history-json` project and it's only a few hundred lines of code and the code doesn't use transactions which means that it can fail and leave the state of the code and database in an inconsistent state.
Being only a few hundred lines of code is a pro, not a con (it's 2,800 including tests: https://tools.simonwillison.net/sloccount?repo=https%3A%2F%2... - lines counted by my vibe-coded port of the classic Perl SLOCCount tool to run in a browser using Perl-in-WebAssembly.)
I lead with sqlite-history-json because I think it's the most impressive of the bunch - it solves a difficult problem in an elegant way with code I would have been proud to write by hand.
Being only a few hundred lines of code is a pro, not a con (it's 2,800 including tests: https://tools.simonwillison.net/sloccount?repo=https%3A%2F%2... - lines counted by my vibe-coded port of the classic Perl SLOCCount tool to run in a browser using Perl-in-WebAssembly.)
It does use transactions in the form of savepoints which means they can be nested: https://github.com/simonw/sqlite-history-json/blob/53e66b279...
Transactions are tested here: https://github.com/simonw/sqlite-history-json/blob/53e66b279...
I lead with sqlite-history-json because I think it's the most impressive of the bunch - it solves a difficult problem in an elegant way with code I would have been proud to write by hand.