Network filesystems do not support the ability to do simultaneous reads and
writes while at the same time keeping the database consistent.
So if you have multiple clients on multiple different
machines wanting to do simultaneous database reads and writes, you have
these choices:
1. Use a client/server database engine. [PostgreSQL][1] is an excellent
choice.
2. Use SQLite in rollback mode. This means you can have multiple simultaneous
readers or one writer, but not simultaneous readers and writers.
3. Host an SQLite database in WAL mode, but do all reads and writes from
processes on the same machine that stores the database file. Implement
a proxy that run on the database machine that relays
read/write requests from remote machines.
[1]: https://postgresql.org/
Generally speaking, if your data is separated from the application by a
network, you want to use a client/server database. This is due to the fact
that the database engine as a bandwidth-reducing filter on the database
traffic.
~~~ pikchr center
box "Your" "Application"
arrow <-> "Low-Bandwidth" "Link" width 250%
box "SQL" "Database" "Engine"
arrow <-> "High-Bandwidth" "Link" width 250%
cylinder "Database" "File(s)"
~~~
If your data is separated from the application by a network, you want the
low-bandwidth link to be across the network, not the high-bandwidth link.
This means that the database engine needs to be on the same machine as the
database itself. Such is the case with a client/server database like
[PostgreSQL][1]. SQLite is different in that the database engine lives on
the same machine as the application, which forces the high-bandwidth link
to traverse the network. That normally results in lower performance.
Choose the technology that is right for you. If your data lives on a
different machine from your application, then you should consider a
client/server database. SQLite is designed for situations where the
data and the application coexist on the same machine. SQLite will still
work if the data is remote, but a client/server solution will usually work
better in that scenario.