If it isn't already, it's worth switching the sqlite database to WAL mode (perhaps even by default, or as an admin option) using "pragma journal_mode=WAL"[0]; I

If it isn't already, it's worth switching the sqlite database to WAL mode (perhaps even by default, or as an admin option) using "pragma journal_mode=WAL"[0]; In standard "journal_mode=DELETE" mode, readers don't block readers, but readers do block writers, and writers do block both readers and writers. In WAL mode, readers do not block writers and writers do not block readers - the only contention is that writers block writers -- so you get much better performance and much less waiting in most use cases. The downsides of WAL mode are: (a) simple file copies are much more fragile - unless you have a "point-in-time" backup, you essentially must use the backup API to copy the database, or alternatively use [1] which does it for you; Best practice is to do that even if you do have a "point-in-time" backup. (b) All processes that use the WAL database simultaneously must be on the same host. This is NOT a requirement for standard mode -- you only need an underlying filesystem without a broken locking implementation[2]..... (I would trust no NFS implementation based on history; No idea if SMB or AFS is trustworthy -- but if your underlying filesystem is good, you actually can do load-balancing / high availability through the file system with a standard-mode sqlite backend) [0] https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html [1] https://stackoverflow.com/questions/25675314/how-to-backup-sqlite-database https://stackoverflow.com/questions/25675314/how-to-backup-s... [2] https://www.sqlite.org/howtocorrupt.html#_file_locking_problems https://www.sqlite.org/howtocorrupt.html#_file_locking_probl...