javascriptgoogle-chrome-extensiongoogle-chrome-appindexeddbchrome-extension-manifest-v3

Chrome extension development: chrome.storage.local vs Indexeddb


I am currently developing a digital wallet application as a chrome extension and trying to figure out what I should use as my persistent storage layer: chrome.storage.local or indexedDb. I have looked into other similar open-source projects, and it seems like most use the former instead of the latter.

I would like to understand if there is any advantage in using one over the other. Currently, the reasons I lean towards using chrome.storage.local are:

I understand that my use-cases and data shape is likely a big factor: As far as my app is concerned

Based on the above, is there any reason that one would serve my application better than the other? Is there anything else I should take into consideration? Thanks in advance!


Solution

  • In Chrome and in Firefox, IndexedDB used by an extension is persistent. In Chrome it's unlimited even without adding "unlimitedStorage" to "permissions" so it uses global quota management, see crbug.com/1209236. I've imported a dummy 40MB JSON (15MB compressed) and it worked. Safari WebExtensions specification is probably much less generous.

    The reasons to use IndexedDB:

    1. Non-string keys and values supported by the structured clone algorithm (Map, Set, Date, RegExp, Blob, File, FileList, ArrayBuffer, ImageBitmap, ImageData, and recently BigInt, Error) in addition to the basic JSON-compatible types offered by chrome.storage.local and .sync (string, number, boolean, null, and arrays/objects that recursively consist of these trivial types).
    2. Storing and reading big or deeply nested objects may be easily 10 times faster or even more.
    3. Checking for an existence of a key without reading its value.
    4. Reading just the names of the keys without reading their values.
    5. Indexing by several keys.
    6. Dedicating an entire object store (or lots of them) per each array that may grow or shrink unpredictably. This will be many times faster (maybe even 1000 if the array is big) than reading the entire array, modifying it, and writing back to a single key in chrome.storage.

    IndexedDB of the extension can't be used in a content script directly, only via workarounds: