IndexedDB performance

Question

Can anyone point me to an article on, or preferably provide some experience of performance of IndexedDB (ideally in Chrome) - what is the fetch, insert and update performanc

Answer 1

I had problems with massive bulk insert (100.000 - 200.000 records). I've solved all my IndexedDB performance problems using Dexie library. It has this important feature:

Dexie has a kick-ass performance. It's bulk methods take advantage of a not well known feature in indexedDB that makes it possible to store stuff without listening to every onsuccess event. This speeds up the performance to a maximum.

Dexie: https://github.com/dfahlander/Dexie.js

BulkPut() -> http://dexie.org/docs/Table/Table.bulkPut()

Answer 2

Doing some performance comparison between IndexeDB and other client side and server side databases. The performance depends of the browser as Firefox implementation of IndexeDB API is much more ahead than Chrome or IE. Firefox is using SQLlite as a backend database, so IndexedDB is implemented on the top of it. You can find many articles of IndexedDB performance, but mostly reserches and developers are saying that IDB perform faster with SQL as a backend. Comparing to Chrome implementation where IDB is implemented on the top of LevelDB(which is NOSQL) is much more slower comparing to Firefox. On the another end WEBSQL(depreciated) is performing fast in Chrome, in Firefox not supported anymore.

I have published a paper with some IndexedDB performance results. https://www.researchgate.net/profile/Stefan_Kimak/publication/281065948_Performance_Testing_and_Comparison_of_Client_Side_Databases_Versus_Server_Side/links/55d3465c08ae0a3417226302/Performance-Testing-and-Comparison-of-Client-Side-Databases-Versus-Server-Side.pdf

Answer 3

I recently did some performance comparisons between WebSQL and IndexedDB. Surprisingly, IndexedDB won (which I wasn't expecting).

http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

---

Edit: the above URL is down, but available on archive.org: http://web.archive.org/web/20160418233232/http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

In summary:

WebSQL takes on average between ~750-850ms to complete the query and render the results; and IndexedDB takes on average ~300-350ms to render the exact same results.

Answer 4

The only performance write-up I've seen is the one produced by @Scott (author of the other answer to this question). Unfortunately, his article doesn't do Web SQL Database justice, since it uses an inefficient HAVING clause to restrict the size of the result set. I tweaked Scott's SQL, replacing HAVING, GROUP BY and LEFT JOIN with (almost) equivalent WHERE and sub-selects:

SELECT p.Name AS ProgramName,
       s.rowid,
       s.Name,
       s.NowShowing,
       s.ProgramID,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Watched', 'Recorded', 'Expected') OR STATUS IS NULL) AS EpisodeCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Watched') AS WatchedCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Recorded') AS RecordedCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Expected') AS ExpectedCount
  FROM Program p
  JOIN Series s ON p.rowid = s.ProgramID
 WHERE s.NowShowing IS NOT NULL OR
       EXISTS (SELECT * FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Recorded', 'Expected'))
ORDER BY CASE
           WHEN s.NowShowing IS NULL THEN 1
           ELSE 0
         END,
         s.NowShowing,
         p.Name

This is about 28 times faster than the original — 20 ms vs 560 ms on my computer — which, by extrapolation from Scott's numbers, makes it about 10 times faster than the equivalent IndexedDB. I wasn't able to confirm this because the IndexedDB code doesn't work in my browser, seemingly due to API changes.

I should explain the "(almost)" I wrote above. Scott's original SQL and mine have subtly different meanings: a gratuitous WHERE clause on my EpisodeCount — which has the effect of replacing a table scan with an index search — may fail to count some episodes if it doesn't cover all possible Status values. Removing this clause erases the difference at the expense of doubling execution time to 40 ms.

Note that, earlier, I discussed with Scott a smaller change to his SQL that also achieves a 40 ms time.

UPDATE: Many thanks to Scott for updating his article to acknowledge the discussion we had.