To clarify a couple of things in response to queries: my time for divestment is "not yet"--but rest assured, when it arrives, I will certainly see who wants things from my assortment (don't get too excited; there's nothing super-rare or valuable in it, and I've always been more concerned with restoring functionality than maintaining period-correctness; I am one of those collectors who restores stuff to play with it, not to then put it in shrinkwrap and preserve it for some uncertain future). And should that time arrive suddenly, well, argh, I've been putting off making a will too long, but I know who I'm going to put in charge of "everything computery," and I trust her to make good decisions about the things she doesn't want. My understanding of sqlite (and it could be wrong) is that concurrent writes aren't supported, and reads should block if a write is in progress until the write completes. In practice it seems like most things are one-sqlite-file-per-process and if that process is threaded, one would hope the programmer understands what they're doing well enough to make it work. There are fairly few cases I've seen where a single sqlite file is shared between unrelated processes, which would take filesystem locking working correctly to ensure correctness. Which is generally OK for local filesystems, but NFS is still a bucket of worms when it comes to locking behavior, and the number of people running systems that genuinely understand NFS has been declining for decades. (I do not count myself among those people.)