Comment by 01HNNWZ0MV43FF

It's also not just "a file on disk". I know this because I re-read the docs about locking last night: https://www.sqlite.org/lockingv3.html

Between this and WAL, which-ever one you pick, you have the following caveats:

- You aren't supposed to use a SQLite DB through a hard or soft link

- By default, in rollback journal mode, it will create a temporary `-journal` file during every write

- If you're doing atomic transactions on multiple DBs, it also creates a super-journal file

- You definitely can't `cp` a database file if it's in use, the copy may be corrupt

- It relies on POSIX locks to cooperate with other SQLite threads / processes, the docs advise that locks don't work right in many NFS implementations

- In WAL mode it needs a `-wal` and a `-shm` file, and I believe the use of shared memory makes it extra impossible to run it over NFS

SQLite is not simple, it's like a million lines of code. It is as simple as a DB can be while still implementing SQL and ACID without any network protocol.

I am thinking of writing a toy DB for fun and frankly I am not sure if I want to start with SQLite's locking and pager or just make an on-demand server architecture like `sccache` uses. Then the only lock I'd have to worry about is an exclusive lock on the whole DB file.