Turbolite serves sub-250ms SQLite joins from S3

This is a smart answer to the wrong question: not "can SQLite run on S3?" but "how much of SQLite's page model do you need to rethink before S3 stops feeling absurd?" For cold, read-heavy multi-tenant databases, turbolite looks promising, but it is still firmly a systems experiment with sharp edges.

• –B-tree-aware grouping is the core unlock; interior, index, and table pages have very different access patterns, so page-at-a-time GETs would waste requests immediately.
• –Query-plan frontrunning is the cleverest trick here; it turns joins into parallel prefetch work instead of a serial miss/fetch chain.
• –The manifest pointer model and seekable zstd frames fit object storage well, but they also create a bespoke on-disk format that will take real hardening to trust.
• –For database-per-tenant or database-per-session apps, the value prop is real: keep cold SQLite files off attached volumes and only pay S3 when those tenants wake up.
• –The single-writer limit, corruption warning, and backend spread all say the same thing: this is not a generic replacement for local SQLite yet, just an ambitious cloud-storage prototype.