2

I've found this particular question: IndexedDB - ObjectStores vs multiple databases vs indices?

However it doesn't fully answer my question. My situation is that I have multiple parts of the application using indexedDb differently. One particular instance of indexedDb needs to be as fast as possible ("high-priority") and it stores only 60-100kb in total. Another one needs to use it much later ("low-priority") when the page renders (possibly after 1-2 seconds) and it can store upto 1.5mb of data.

Currently I have each part of the application call a common indexedDb library to create their own instances of indexedDb , which results in 4-5 instances.

Now my question is, would it be better to move these different instances into a single instance with multiple objectstores. And each instance can interact with their own objectstore with their own key.

enter image description here

Here number 1 would be the existing architecture and number 2 is the new proposal design.

Essentially my question is, would moving to number 2 proposal cause "high-priority" table to be accessed slower than before? If the change isn't drastic, I'd like to move to number 2 to avoid opening multiple indexedDb instances hence making the overall performance better.

Kemal Tezer Dilsiz
  • 3,739
  • 5
  • 24
  • 43

2 Answers2

2

I would suggest you go with a single database. The performance load on certain collections will not significantly impact the performance load on other collections.

Josh
  • 17,834
  • 7
  • 50
  • 68
2

I've done a test for this scenario where I did indexedDb.open() for two different indexedDbs. One of the with the size of 28mb and the other with the size of 1kb.

The difference was minimal (1.8ms vs 2.2ms) when using performance API to measure the time it took.

Wai Ha Lee
  • 8,598
  • 83
  • 57
  • 92
Kemal Tezer Dilsiz
  • 3,739
  • 5
  • 24
  • 43