getAll() good enough to get top performance out of IndexedDB? Do we also need native joins or
There’s been some discussion about bringing better integration with promises or explicit transaction support to IndexedDB. But from the PouchDB perspective, our biggest ask for IndexedDB 2.0 would be neither promises nor transaction control, but rather better bulk APIs to get faster performance. In several performance tests (e.g. this one), we’ve seen WebSQL perform up to 40x faster than IndexedDB for bulk reads in Chrome. Writes are about the same.
getAll() is going to help a lot with that (described here, we haven’t started using it yet in PouchDB). But we could possibly leapfrog WebSQL for write speed if we also had a
putAll(). (Question: would this actually be any faster than just doing multiple parallel
Another big win for PouchDB would be some kind of native “join” with
getAll(), since our pagination implementation (
allDocs()) currently involves using an IDBCursor and manually joining two object stores, which means a lot of separate requests and therefore a lot of waiting. Whereas in WebSQL, we can just write a single query using
JOIN and whatever criteria we want inside of the
WHERE. This is a huge win for performance and is largely where that 40x number comes from.
getAll() mitigates this somewhat for the primary object store, but when joining the second object store, we still have to do a bunch of separate
get() requests because we need to fetch based on a list of keys. (Or we could sort the keys and use a cursor, but in the past I haven’t found this to be faster). Maybe the multiple parallel
get()s aren’t so bad, though; I haven’t tried it out yet.
At some point soon, I’ll implement
getAll() support in PouchDB and report back how much it affects performance. In the course of writing this post, I’ve started to wonder if
getAll() doesn’t solve most of the problems I’ve outlined.