I believe Plex uses synchronous=NORMAL.
I don’t think Plex uses TEMPORARY tables directly.
Are there transient objects this would benefit? Complicated joins that use temporary indexes? Do you know how to find out?
SQLite uses cache_size * page_size = memory for caching. And page_size - the next item on your list - is weirdly small. So the result is very small.
I expect moderate increases to help moderately. I don’t expect huge increases to help hugely.
This is easy to benchmark synthetically. Do you have ideas for how to benchmark this in Plex?
Binary hacking is fun:
sed -i.orig \
-e 's/cache_size=2000/cache_size=8192/' \
-e 's/cache_size = 4096/cache_size = 8192/' \
'Plex Media Server'
100% agreed. This is an obvious change.
1024 is anachronistic in 2022, and I can’t think of any reason for the ancient value.
For anybody reading along, here’s how to increase page_size of an existing SQLite db file:
# Show the original page_size
"Plex SQLite" com.plexapp.plugins.library.db "PRAGMA page_size"
# Set the desired page_size,
# disable WAL,
# VACUUM to rewrite the pages
# re-enable WAL (not strictly necessary, Plex will do this)
"Plex SQLite" com.plexapp.plugins.library.db "PRAGMA page_size=4096" "PRAGMA journal_mode=DELETE" "VACUUM" "PRAGMA journal_mode=WAL"
# Show the new page_size
"Plex SQLite" com.plexapp.plugins.library.db "PRAGMA page_size"
4096 is still very conservative and is a significant improvement. Larger values can help too but might be filesystem-dependent.
I don’t think this is viable, Plex uses a connection pool.
Does it help much when in WAL mode? I haven’t tested in forever.
And it would block direct updates, which would be annoying. 
This is interesting!
This might help big databases on fast storage. Would it help the “average” user much?
mmap would be scary from Plex’s perspective. The variety of operating systems and filesystems, the different failure modes from mmap. People complaining about mmap “using too much memory”.
