It’s mostly about throwing ACID at the problem, sqlite just happens to be battle-tested to a ludicrous degree, it’s light enough to not be unconscionable overhead in simple situations (unless you’re on embedded), and performant enough to also deal with nastier situations so I prefer it over some random K/V store with the same guarantees. It’s also a widely-used and stable data format which might come in handy.
That said, if you want to go lightweight do consider good, ole, POSIX filesystem guarantees, in particular that mv is atomic (as long as you stay on the same filesystem but that’s easy to ensure by mv’ing within a directory). That’s not durable on its own, you’ll need to fsync for that, and consistency and integrity is up to your code.
You can’t know that from my issue description, but throwing a database at that problem really is ridiculous overkill.
Still thanks for the suggestion
It’s mostly about throwing ACID at the problem, sqlite just happens to be battle-tested to a ludicrous degree, it’s light enough to not be unconscionable overhead in simple situations (unless you’re on embedded), and performant enough to also deal with nastier situations so I prefer it over some random K/V store with the same guarantees. It’s also a widely-used and stable data format which might come in handy.
That said, if you want to go lightweight do consider good, ole, POSIX filesystem guarantees, in particular that mv is atomic (as long as you stay on the same filesystem but that’s easy to ensure by mv’ing within a directory). That’s not durable on its own, you’ll need to fsync for that, and consistency and integrity is up to your code.