Nice work! > The read API is unfortunately synchronous: every read requires us to wait for the read result from an object storage device (OSD). It would be better if SQLite could initiate every or as-many-as-can-fit-in-page-cache reads it requires to execute a query before using the results. This sounds like a tall order to me, in terms of the replumbing of SQLite that'd be needed; but one complementary idea I've wondered about idly (for [sqlite_web_vfs](https://github.com/mlin/sqlite_web_vfs)): could we gain something by aggressively prefetching all the ['interior' b-tree pages](https://sqlite.org/dbstat.html) -- supposing we kept a list of their page numbers stashed somewhere? I've been meaning to run some experiments to convince myself quantitatively whether that's a good idea, i.e. are they a small enough proportion of the database file and would having them all upfront save enough serial roundtrips. LMK if you might like to join forces on that. Also neat would be if there were a way to make the pager try to store interior pages contiguously, which (correct me) I don't think is a goal right now, even for vacuum.