https://github.com/nsrht/time-travel-sqlite-debugger/blob/ma... works by checking the mtime on the database file (and -wal file) once per second and creating a backups/unixtime_database.sqlite file if anything has changed, then keeps the last 50 copies.
So OK for smaller database files but not great if you're pushing into a GB+ of data.
I'm not convinced by the way it copies the files - I think using a "vacuum into" backup would be safer then file copies.
Litestream offers point-in-time recovery for SQLite by backing up chunks of WAL directly, which I expect is a lot more efficient than this mechanism.
Of course safeAtomicCopy only ensures that the output is atomic, it doesn't lock the database in anyway. So yes, you will get corruption. It also attempts to support WAL but just copies the extra files afterwards without any locking so even more corruption.
So I would definitely heed the warnings that this is not for production use.
So OK for smaller database files but not great if you're pushing into a GB+ of data.
I'm not convinced by the way it copies the files - I think using a "vacuum into" backup would be safer then file copies.
Litestream offers point-in-time recovery for SQLite by backing up chunks of WAL directly, which I expect is a lot more efficient than this mechanism.
Of course safeAtomicCopy only ensures that the output is atomic, it doesn't lock the database in anyway. So yes, you will get corruption. It also attempts to support WAL but just copies the extra files afterwards without any locking so even more corruption.
So I would definitely heed the warnings that this is not for production use.