I wouldn't recommend using SessionStorage

[dmurph]

SessionStorage is per-tab (with navigation-inheritance from navigated-from tabs), while the rest of these storage systems are per-origin. This means that if you have multiple tabs / contexts, and they are all doing changes, then sessionstorage will always be wrong on all of them. Also, it will have to have unique data per tab / context, so you'll get a per-tab copy of the data in session storage on disk, which means (other than the already duplicate data being stored in other storage systems), tabs*data size extra data.

Also, the first get or put (on both SessionStorage and LocalStorage) actually does a synchronous read from disk. This is unfortunately by design of the very old spec, as the API is synchronous. So just keep that in mind, this isn't great for the user, as the page freezes, and it can be bad for machines that are old / spinning disk / slow.

(I'd also recommend just using IndexedDB by itself and not using any of these other storage backends... but that's a separate issue, and probably not a constructive one)

[dmurph]

Also cookies do synchronous disk read as well

[gruns]

Wonderful observations, thank you.

I'll excise SessionStorage from the data stores shortly.

[gruns]

I removed SessionStorage from ImmortalDB's default data stores in
01b1677. This change will ship in the next version of ImmortalDB, v1.1.

Thank you for bringing this to my attention, Daniel. Don't hesitate to let me
know if there's anything else I can do for you.