How is indexedDB conceptually different from HTML5 local storage?

Question

1. Both indexedDB and local storage are key value stores. What is the advantage of having two key/value stores?
2. indexedDB is asynchronous, but joins (the most ti

Answer 1

I came across this good article discussing about localstorage vs indexeddb and other possible options.

(all the below values are in milliseconds)

https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/

To summarize from the article (entirely author's views),

1. In all three of Chrome, Firefox, and Edge, LocalStorage fully blocks the DOM while you’re writing data 2. The blocking is a lot more noticeable than with in-memory, since the browser has to actually flush to disk.
2. Not surprisingly, since any synchronous code is blocking, in-memory operations are also blocking. The DOM blocks during long-running inserts, but unless you’re dealing with a lot of data, you’re unlikely to notice, because in-memory operations are really fast.

3. In both Firefox and Chrome, IndexedDB is slower than LocalStorage for basic key-value insertions, and it still blocks the DOM. In Chrome, it’s also slower than WebSQL, which does blocks the DOM, but not nearly as much. Only in Edge and Safari does IndexedDB manage to run in the background without interrupting the UI, and aggravatingly, those are the two browsers that only partially implement the IndexedDB spec.

4. IndexedDB works swimmingly well in a web worker, where it runs at roughly the same speed but without blocking the DOM. The only exception is Safari, which doesn’t support IndexedDB inside a worker, but still it doesnt block the UI.

5. localmemory is ideal if data is simple and minimal