Comparing JSON (gzipped or not) in localStorage with IndexedDB (using PouchDB)

By Israel Martínez Valdés

I wrote last week about GZipping JSON for localStorage and, over the weekend, I decided to do some checks on the efficacy of this approach. I noted that the larger the payload, the more significant the space saving; smaller payloads often negated any saving, with the gzipped file being significantly larger than the original JSON for smaller JSON payloads.

I didn't only compare the original JSON and the gzipped JSON though, I decided to take a wee look into IndexedDB, with the help of PouchDB.

I worked with three JSON files:

1. bodies.json (330 KB)
2. employees.json (2284 KB)
3. family.json (2 KB)

As you'll be able to see from the code, I do a fair bit of computation using both console.time() and performance.now().

The results are output to the developer console (I did try using a Donut Chart - but I discovered a bug in my Component - I'll fix it this week, hopefully!).

The following are my results for saving on Firefox:

1. 1. Time taken to save bodies using localStorage: 0ms
   2. Time taken to save bodies with Pako: 20ms
   3. Time taken to save bodies with PouchDB: 34ms
2. 1. Time taken to save employees using localStorage: 0.002ms
   2. Time taken to save employees with Pako: 69ms
   3. Time taken to save employees with PouchDB: 149ms
3. 1. Time taken to save family using localStorage: 0ms
   2. Time taken to save family with Pako: 2ms
   3. Time taken to save family with PouchDB: 157ms

And these are my results for retrieving the data on Firefox:

1. 1. Time taken to get bodies using localStorage: 2ms
   2. Time taken to get bodies with Pako: 10ms
   3. Time taken to get bodies with PouchDB: 45ms
2. 1. Time taken to get employees using localStorage: 12ms
   2. Time taken to get employees with Pako: 25ms
   3. Time taken to get employees with PouchDB: 22ms
3. 1. Time taken to get family using localStorage: 1ms
   2. Time taken to get family with Pako: 1ms
   3. Time taken to get family with PouchDB: 43ms

The following are my results for saving on Chrome:

1. 1. Time taken to save bodies using localStorage: 0ms
   2. Time taken to save bodies with Pako: 6.5ms
   3. Time taken to save bodies with PouchDB: 185.1ms
2. 1. Time taken to save employees using localStorage: 0ms
   2. Time taken to save employees with Pako: 54ms
   3. Time taken to save employees with PouchDB: 143.89ms
3. 1. Time taken to save family using localStorage: 0ms
   2. Time taken to save family with Pako: 0.4ms
   3. Time taken to save family with PouchDB: 178.5ms

And these are my results for retrieving the data on Chrome:

1. 1. Time taken to get bodies using localStorage: 0.9ms
   2. Time taken to get bodies with Pako: 4.29ms
   3. Time taken to get bodies with PouchDB: 39.6ms
2. 1. Time taken to get employees using localStorage: 5.19ms
   2. Time taken to get employees with Pako: 27.9ms
   3. Time taken to get employees with PouchDB: 19.2ms
3. 1. Time taken to get family using localStorage: 0ms
   2. Time taken to get family with Pako: 0.19ms
   3. Time taken to get family with PouchDB: 34.69ms

The results (in chart form) are here:

I think we can probably all tell that localStorage wins, and wins handsomely. Though the limitations of space in localStorage means that IndexedDB still has a place; perhaps not for smaller data sets though.

I'm happy that I've taken the time to find this out; it certainly means that I have evidence for future decisions - I'd be interested in analysing it further, though, especially as there are discrepancies between the different browsers. Saving to IndexedDB on Firefox seems much faster than on Chrome, though the situation is reversed when retrieving data from IndexedDB.