Heh, I wonder how many people will delete the "wal" file thinking that, since they switched to wal2, the wal file must be a leftover.
IMHO this (having a variable number of files containing the data, depending on your configuration) is the only real design quirks of this technology.
If you're using it as a standalone file format you presumably shouldn't leave .sqlite files with associated wal files lying around in places where users are going to get confused by them, either by sticking to the rollback journal mode or by using some other method
Also, a scheduled backup process might come along at any moment and non-atomically copy the database file and any -journal or -wal files.
Ideally, user visible files should survive copying at random points in time without corruption and without losing too much recent data.
Having read "How To Corrupt An SQLite Database File"[1], I'm still not quite sure how to achieve this.
I know reading the manual isn't very common and people are lazy, but getting burned can be a useful and necessary lesson.
It happens.
(I'm really, really hoping the "previous" person wasn't me.)
You make mistakes. Do you want them to be as painful as possible?
I've been bitten badly by that issue once. I just mounted the .db file into a docker container and didn't realize that sqlite creates wal files. On an non-graceful shutdown of the application the wal file was not merged into the db and the container deleted. And around a day of changes were lost.
Conclusion: Sqlite databases should be placed into their own folder, so it's obvious that it's not always just one file.
When using WAL, if you’re copying or backing up the database it’s possible to force a checkpoint, then you can copy the .db file alone knowing exactly up to when it contains data.