My idea is to modify SQLite to use ajax with the HTTP Range header to fetch B+ pages from the server as they are needed. SQLite already has a VFS (virtual file system) so this shouldn't be too hard.
I am not sure how fast it would be and it would waste a lot of bandwidth. That's why I haven't made it yet.
This would only be useful for using it with Github pages.
They are used to share structured and unstructured data in a p2p way where a torrent could be a database(structured) or a fileset(unstructured) .
But all of this is part of a bigger project that is basically a new sort of p2p "app browser" with a local-first emphasis but where every app can share its functionality though RPC (locally or remotely) with distribution going over DHT's and torrents.
> The upper bound on [the number of keys on an interior b-tree page] is as many keys as will fit on the page.
I think a tricky part of this idea would be the locking. Usually SQLite relies on the locking of the underlying filesystem. You could add your own mechanism that causes a lock to be assigned to a single client connection, but what if it never unlocks? (On a single machine you can tell if the client process has crashed.) You could add a timeout but what if the client process then does respond?
It is going to be read only.
Locking wouldn't be problem because in the eyes of the sqlite running in the browser it would have it's own read only copy of the database.
Even with an artificially slow connection it seems to be reactive enough. Actually fetching pages on-demand can only be better for the bandwidth, the real issue is going to be latency