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.

> localStorage is not durable

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.

We do have volatileStorage: it’s `sessionStorage`

We do need better permanent storage.

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).

> presumably because they don't want webapps competing with their iOS ecosystem

Or because trackers are using indexeddb to bypass Safari's anti-tracking and privacy measures.

Perhaps. They could easily stick it behind a permission if that was what they were worried about though.

Give an inch, and advertising will take a mile.

No doubt it’ll no doubt leak some number of bits that differ between platforms and browsers and that will be used to identify and track users.

IndexedDB should perform better without locking the browser context.

Yea, my mobile Chrome (pixel 3) hang on the UI thread a lot, can't even scroll till it yields.

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.