> You have to be able to architect your application to send all write traffic to a single process ...

Counter-point: sqlite's sister project and SCM, the Fossil SCM, is a self-hosting sqlite client application and has been since 2007. Every hit on the fossil-scm.org website is its own standalone fossil process accessing the same copy of the same db file, all while the developers are actively pushing and pulling changes to/from that same db and while half a dozen or so folks are logged in to its /chat room (each instance of which is long-polling that same db 24/7).

In 14 years of using that db i've encountered _maybe_ two locking errors.

Similarly, sqlite3's own forum is a fossil instance hosting a single sqlite3 repository.

That all writes "have" to be channeled through a single manager is demonstrably not the case.