I ran into the IndexedDB slowness problem while adding support for it to Converse.js XMPP messenger[1].
I'm using localForage which lets me persist data to either sessionStorage, localStorage or IndexedDB (depending on user configuration), however writes to IndexedDB were excruciating slow.
I didn't want to give up on it however, because localStorage has a storage limit that power users were constantly coming up against, and IndexedDB is also necessary for progressive web apps.
Eventually I solved the problem by batching IndexedDB writes with a utility function I wrote called mergebounce[2]. It combines Lodash's "debounce" and "merge" functions to combine multiple function calls into a single one, while keeping and merging the data that was passed to the individual function calls.
That way, you can call a function to persist data to IndexedDB many times, but it only executes once (after a small delay). I wrote a blog post about this approach[3]. It's generic enough that anyone else who uses localForage for IndexedDB could use it.
Depends how complex your needs get, IMO. localStorage is a key/value store, IndexedDB is a (basic) database. (localStorage also ties up the main thread whenever its in use, which also becomes relevant if you're using it a ton)
Comments
I ran into the IndexedDB slowness problem while adding support for it to Converse.js XMPP messenger[1].
I'm using localForage which lets me persist data to either sessionStorage, localStorage or IndexedDB (depending on user configuration), however writes to IndexedDB were excruciating slow.
I didn't want to give up on it however, because localStorage has a storage limit that power users were constantly coming up against, and IndexedDB is also necessary for progressive web apps.
Eventually I solved the problem by batching IndexedDB writes with a utility function I wrote called mergebounce[2]. It combines Lodash's "debounce" and "merge" functions to combine multiple function calls into a single one, while keeping and merging the data that was passed to the individual function calls.
That way, you can call a function to persist data to IndexedDB many times, but it only executes once (after a small delay). I wrote a blog post about this approach[3]. It's generic enough that anyone else who uses localForage for IndexedDB could use it.
1. https://conversejs.org 2. https://github.com/conversejs/mergebounce 3. https://opkode.com/blog/2021-05-05-mergebounce-indexeddb/
localStorage doesn't work for progressive web apps?
It works the same way the glove compartment in your car works when driving for a holiday / to see relatives....
You grab stuff easily out of it, but not much'll stay in there.
Depends how complex your needs get, IMO. localStorage is a key/value store, IndexedDB is a (basic) database. (localStorage also ties up the main thread whenever its in use, which also becomes relevant if you're using it a ton)
Local storage is typically 5mb.
Not sure what PWA would survive on that.
I see, it has a lower quota and only IndexedDB has a mechanism to request persistence.
Thanks.
Thanks for the post, just a heads up the localForage link in your blog post leads to a 404 page.
Fixed, thanks!