IndexedDB size keeps growing even though data saved doesn't change

Question

I am using Redux Persist and LocalForage in my web application. I have a series of actions that are fired upon login that update some data about the user. The IndexedDB size after all actions are fired and the data is saved in the JSON format on indexedDB is ~1.4Mb.

However if I refresh the page thus triggering again the actions, or if log out and back in, even though the values inside IndexedDB DO NOT change (I have double checked with a JSON diff tool), the size of the storage keeps on growing. Eventually Chrome will clear some of it after it grows for a few MBs, but not going back to the initial correct size.

The IndexedDB JSON is exactly the same, no differences whatsoever, but huge difference in size. Does anyone know why this is happening and how can I prevent it? I also would like to know when/how often Chrome clears whatever data it is that is cluttering my IndexedDB, but I haven't been able to find any reference for it.

Thanks a lot

Compact

I found this question after discovering my IndexedDB has grown to 37gb for 1gb worth of content. Did you find a solution to shrink/comtact the database? – Spodumene

Answer 1

Chrome uses LevelDB as a backing store for Indexed DB. You can read more about LevelDB at: https://github.com/google/leveldb

LevelDB is optimized for fast reads and writes. Space is lazily reclaimed through compaction.

Noahnoak

Answer 2

I noticed the same behaviour in a Web-Application I am currently working on.
After doing some research, I found, that Chrome keeps old (deleted) Database-Files and only marks them as deleted. Also it will probably do some performance optimization which might increase space over time.
But once it reaches a specific size, it will automatically try to compress the database. I wanted to confirm this behaviour and added some code, which automatically reloads the webpage, once the data has been written into the Database.
In my case, the space needed by IndexedDB grew up to about 3.3MB. As soon as it reached this size, it has been compressed to about 1.3MB and started to grow again.

Orgell

Same here. I also noticed that the size where it compress/clear the data is variable and tend to raise but at some point it clear everything again. I tried with my 300k db, at first it cleared from 3.3MB to ~1MB, then it kept raising and after some time it was ~10MB when it cleared to ~8MB and then when I reached ~13MB came back to 1.5MB – Shewchuk

Unfortunately this is especially tricky when working with extremely limited quotas (e.g. on SoC or embedded devices). I tested a 2MB quota on a data set of only 440kb and after a few reloads, it'll bloat to >2MB, at which point it's stuck in the error state throwing QuotaExceededError, even though the object store is cleared each time and the set is <500kb. 😞 – Varia