No. These are internal SQLite defaults. FDB sets the page size to 4096 when creating a new SQLite database file. That line is here and changing the size to something else is completely untested. I doubt it will work, or it may work with worse performance, because of how SQLite’s file access works in FDB.
SQLite’s file operations are routed through a caching layer called AsyncFileCached. There are 2 page caches instanced, a 64k page cache for SQLite WAL (write-ahead-log) files and a 4k page cache for SQLite’s main page file and all other files. SQLite uses “zero copy reads” which AsyncFileCached requires to be exactly pageSize (4096) in length or it throws an io_error exception. It’s possible (I have not checked) that when this happens it will fall back to non zero-copy reads, but if so performance will be terrible. Without zero-copy reads, most page accesses by SQLite will incur a page copy, even pages that are already in the cache (FDB’s cache) because from SQLite’s perspective it is reading from the filesystem. SQLite has an internal page cache but it is intentionally configured to be very small so that FDB’s code can manage which pages are cached and can share the page cache capacity across all users of AsyncFileCached.
You can try modifying AsyncFileCache.actor.h/cpp to change the 4k page size to some other page size. It might work to just change all instances of 4096 in those files to some other page size but you will also have to instance a FastAllocator<> for the new page size if it is larger than 8192 or you will get compile errors. You could also just not change the checks which are trying to use FastAllocator<4096>, but then it will use slower memory allocation for each cache entry creation.