OK, I'll download the PDF onto my phone and get the quote...
...I forgot how significant these problems are. These are quite serious.
"However, WAL mode has notable disadvantages. To accelerate
searching the WAL, SQLite creates a WAL index in shared memory.
This improves the performance of read transactions, but the use
of shared memory requires that all readers must be on the same
machine. Thus, WAL mode does not work on a network filesystem.
It is not possible to change the page size after entering WAL mode.
In addition, WAL mode comes with the added complexity of checkpoint operations and additional files to store the WAL and the WAL
index."
It also complicates backups. I have another process that .backups the database but even when opening it in read-only it creates a .wal file. My first version of the backup script didn't delete it afterwards and the normal process didn't have the right to overwrite the backup's wal file so opening the db failed
I wonder how many times SQLite has been passed over for a more complex solution because people thought they needed highly scalable distributed two phase commit or whatever when all they really needed was a file with an SQL interface
I'm guessing your response was sarcastic. I don't get it, though. If you need a distributed two-phase commit DB get one like CockroachDB or something like that. SQLite is not that.
The chief problem that I see with WAL is that it breaks ACID with databases that are ATTACHed, as the documentation shows:
https://sqlite.org/lang_attach.html