This is a notice of intent to experiment. :) I tried to use a SQLite database backend several years ago and it turned out not great. There were several issues at the time; performance, lack of required concurrency in some cases, and difficulty in cross compilation. This time I intend to take a slightly different approach, with slightly different goals, and also things have changed in the wider ecosystem.

• Instead of using it as a dumb key-value store I will use wider tables with at least some fields of the underlying data exposed as columns. The intention is to use native SQLite indexes and processes for a lot of the metadata housekeeping we do manually today.
• If having long running write transactions is still a problem I'll work to split them up -- for example, having a puller iteration be for only a subset of files rather than all that are needed at the time. For ordering items (by size, modification time, etc) we can use SQL constructions with a limit clause.
• There are multiple implementations of SQLite available, the most common being the regular C implementation with a wrapper, which we can use for most builds. For the more exotic builds there is a Go translation of the C source code, which is equally cross compilable to what we have today. We can use either or both as required.
• I'm willing to accept a certain level of performance degradation if it results in improved stability and maintainability.