I have seen SQLite disconnect random sessions of multiple writers, rather than blocking them. Setting WAL mode made no difference.

This database can safely be used by a single writer at all times.

To implement the serialization that SQLite does not, do this in the POSIX shell:

  until mkdir ~/.dpapplock 2> /dev/null
  do sleep 3
  done

  trap "rmdir ~/.dbapplock" EXIT
  sqlite3_app ...

The mkdir() system call is defined as atomic by POSIX, so the shell can safely serialize for you, assuming there are never more than a handful.

My understanding is that SQLite suppprts only system locks. So multiple writers will need to be either blocking on system level or implement some other form of locking to ensure integrity.

A great deal of complexity of DBMS is in granularity of locks, its escalation/deescalation, and shared use performance.

I wonder if one day SQLite would support synchronization/replication protocol. In a way Fossil SCM is an attempt at SQLite replication, albeit a specialized one.