'IndexedDB - ObjectStores vs multiple databases vs indices?
I was wondering when it would be a good idea to have a single database vs one database with multiple object stores. I've read most tutorials on the web as well as looked at the specification for indexedDB, but could not find a good example comparing these different concepts. Does anyone have a concrete example (a design model using multiple object stores and/or code) for this sort of thing?
Solution 1:[1]
As long as there is no cross transactional manipulation among object stores, you can separate them into multiple databases. I prefer to use separate database, as many as possible, so that schema changes are easier in smaller object store database.
In rare situation, I even use separate database even if cross transaction is require. These cases are found between user setting database and application database. Inconsistency between user setting and application are fine, since the truth is in user setting and temporary inconsistency does not matter.
Notice that there is high cost associate with opening a database. But once it is open, there is no memory consume for the connection. There is no limit in number of databases.
Multiple databases will have higher thourghput than single database with multiple object stores, since implementation of Firefox lock down whole database on any write transaction.
Solution 2:[2]
I did several performance tests and opening multiple databases with one store each is much much slower then opening a single database with multiple stores. So you should always only open one database and reuse that one by adding more stores. You can reproduce the tests results here
I also did many tests on why IndexedDB is slow and how to evade the slowness here
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Kyaw Tun |
| Solution 2 | pubkey |