The fundamental issue with networked disk vs. local disk is latency. This can be accomodated in many workloads by queuing up i/o requests (see also readahead, asynchronous i/o), however any application which relies on the idiomatic read/write syscalls will suffer somewhat against a network fs especially if it is seeking around. sqlite's workload is very seek heavy and there's no reasonable way to anticipate which pages of the database file will be needed in advance, so it is especially affected by latency. > I would expect Linux needs some special configuration option to say "this network file is static, please cache it whenever it is opened". Yes, many network caching options and configurations exist, each with various features/compromises. But sqlite calls fsync() regularly to ensure database consistency and this likely bypasses any advantage you might get from caching. If the DB legitimately never changes you can tell sqlite when opening it to use [immutable mode](https://sqlite.org/uri.html#recognized_query_parameters), and with a sufficiently large [page cache](https://sqlite.org/pragma.html#pragma_cache_size) that should ensure the DB isn't read more than once. However in that situation I would also question what benefit the DB is offering over eg. a flat file stored in /dev/shm