SQLite has a system that abstracts various low-level storage operations called VFS - this is the layer that allows SQLite to be portable across different operating systems and environments: https://www.sqlite.org/vfs.html
Recently I’ve wondered how possible it would be to implement a SQLite VFS on top of IndexedDB - and, would such a VFS be competitive in speed to using IndexedDB directly? Or, would it be equivalent to use Emscripten’s existing POSIX-ish filesystem backed by IndexedDB?
An IndexedDB VFS would allow sql.js to durably persist data in the browser.
What if SSDs just had an alternative interface that talked SQL? Presumably you could bake SQLite into the microcontroller and optimize perfectly for the storage scenario. Having your journaling aware of how long your supercapacitor will last in the worst case could open the door for some wild optimizations.
There have been some projects to develop SSDs that natively present a key-value storage interface, and standardization of that is pretty far along. So those drives can function as a backend for eg. a RocksDB substitute with a minimal software frontend.
But a full SQL database engine on the SSD would fall under the umbrella of computational storage, and so far everyone with the resources to put any of that into production has datasets that don't fit on a single drive. So there's less utility in having the drive speaking proper SQL, but a lot of active research into how to usefully offload some of the DB work onto compute resources that reside on the SSD itself.
(Also, microcontroller is a bit odd to use to refer to the main controller chip inside a SSD, especially a high-end enterprise SSD. It gives a completely misleading indication of scale.)
> Recently I’ve wondered how possible it would be to implement a SQLite VFS on top of IndexedDB
What is interesting about this approach is that at least for Firefox, IndexDB is implemented using SQLite. So ultimately this approach is SQLite running in SQLite with an IndexDB layer in the middle.
Yeah, the the teetering architecture tower is certainly worth an eye-roll given that WebSQL - basically SQLite direct access - was almost accepted as a standard, but was ultimately blocked by Mozilla [https://en.m.wikipedia.org/wiki/Web_SQL_Database] while they pushed this IndexedDB monstrosity.
It was blocked because the standards bodies require two or more independent implementations. All Mozilla said was that if they were to implement WebSQL they would use SQLite and there would not be two different implementations. Why should have Mozilla had the burden of implanting WebSQL in a different database?
No it's not. WebSQL would have become "WebSQLite", quirks and all. That's not good for anyone. Any quirks in SQLite (of which there are _many_) would immediately become unfixable parts of the spec.
Sure would be a shame if a web standard reified implementation quirks as a durable part of the spec, something which has never happened before in the history of the World Wide Web.
Yes, it would be as much a shame now as it was then. This might come as a surprise but you can actually _learn_ from past mistakes and attempt to avoid them in the future. Like websql.
SQLite is a large, complex project by itself. Not only would you be adding it’s quirks into the spec but you’d be basically locked into a specific version of SQLite that has to be bug for bug compatible with whatever version was shipped before.
It’s quite clearly a terrible, terrible idea. And I say that as someone who was quite looking forward to what WebSQL has to offer. It’s more a reflection on “there is only one embedded SQL database suitable for use” than anything else.
Similarly, would like to see SQLite work over a WASI's File System interface... best would be the ability to also support multi-process, but I don't know that it would be possible.
Google has a project called Lovefield [1] that is a SQL-like thing on top of IndexedDB. Not exactly SQLite and I'm not sure what its status is now but might be of interest.
I've actually prototyped this recently, but never got around to packaging it up into a library.
There are a few neat adjacent things that it can be used for (e.g. opening big SQLite files on disk without reading it all to memory), building something like Datasette (https://github.com/simonw/datasette) that can run queries on data hosted as static files, or for (as you suggested) using SQLite in a browser with persistence.
For that particular use case, there's a bit of complexity related to mutexes and stuff in trying to prevent simultaneous browser tabs doing write operations from corrupting the database.
What you really want for this is SQLite4--which added an abstraction layer below the database and above the VFS which could use a key-value store--but sadly I think it ended up being scrapped :(.
Cookies are not a good spot for bulk data because each request to the server includes all the cookies. You wouldn’t want your whole SQL database included in each fetch() request.
localStorage is not durable. At Notion, we observed Chrome localStorage losing writes under load from multiple async writers. IndexedDB is the most durable option, but has quite an annoying and error-prone API, which is why it would be nice to paper over it with SQLite so browser code can use the same schemas and queries as native clients.
Side tangent: Why in 2020 do we find the state of localStorage to be acceptable?
There's two problems that I see with localStorage:
- It's too easy for someone to blow it away and lose data for a web app
- Not enough capacity to be useful for a lot of things. (10 megabytes per domain)
The design of localStorage is basically flawed, IMO. It should have been two things: volatileStorage and permanentStorage. volatileStorage would basically be exactly what localStorage is today, being very limited and not requiring any permissions. permanentStorage would be like localStorage except it would require explicit permission, allow unlimited storage, and would be more difficult to accidentally delete(separate delete dialog from Clear History).
As far as I know, we don't have anything like my proposed permanentStorage outside of web extensions, which leaves localStorage in a weird area where it's only really useful for local app settings, even though such sparse data is easy enough to just store on a server in the first place. It would still be useful for truly offline-first apps, or apps that don't require accounts, but then this space of apps is still crippled by limited storage capacity.
indexedDB is the closest thing to permanent storage. This works quite well in Chrome/Firefox. But Apple don't persist it properly (presumably because they don't want webapps competing with their iOS ecosystem).
I get a lot of that on mobile advertising on my phone (Android). It causes jittery behavior trying to just scroll... usually open in brave and it works a little better (opinions on brave itself aside, it just happens to work better for me than other adblock options).
The file size limits on cookies and localStorage might make it a bit impractical for the kinds of things you'd want to store in a database. You won't be caching many image files that way, for example.
Recently I’ve wondered how possible it would be to implement a SQLite VFS on top of IndexedDB - and, would such a VFS be competitive in speed to using IndexedDB directly? Or, would it be equivalent to use Emscripten’s existing POSIX-ish filesystem backed by IndexedDB?
An IndexedDB VFS would allow sql.js to durably persist data in the browser.