Can you separate concerns using multiple object stores efficiently? When would you avoid that?

Question

Ponu Maurya · Answer

Yes, you can and should separate concerns using multiple object stores in IndexedDB — but it depends on your app’s complexity and access patterns. Here’s when to do it, when not to, and how to do it efficiently. When You Should Use Multiple Object Stores Use Case: Clearly Different Entities If your app has different types of data (e.g., users, notes, settings), each should live in its own store. Example: Benefits: Benefit Why It Helps Separation of concerns Easier to maintain and reason about data Targeted queries You query only what you need (e.g., only notes) Custom keyPath per store users may use id, settings use key Easier migrations You can upgrade one store without affecting others When to Avoid Too Many Object Stores Too many stores can be overkill and inefficient. Avoid if: You just want to categorize similar items (use a type field instead).You plan to query across multiple stores (joins are hard in IndexedDB).Your entities are tightly coupled and always used together. Example: If you're storing: You could use a single items store with a type field and index on type. Efficient Multi-Store Use Tips 1. Use Indexes Instead of Separate Stores for Categories Then: 2. Avoid Unnecessary Transactions Only open a transaction for the store(s) you need: 3. Batch Related Data Together (if tightly coupled) If you always access a note and its tags together, maybe they should be stored together. Rule of Thumb Decision Point Recommendation Clearly different data types Use multiple stores Same structure, just different categories Use one store with a type field & index Need to query across stores Use a single store or denormalize Need to version or migrate independently Use separate stores Example Design: Multi-Store Each store handles a single responsibility — making updates, queries, and migrations clean and isolated. Conclusion Multiple object stores are efficient when: Data types are unrelatedYou want better organizationYou avoid cross-store joins Avoid them when: Data is tightly coupledYou’d need complex joinsIt leads to excessive schema complexity

Benefit	Why It Helps
Separation of concerns	Easier to maintain and reason about data
Targeted queries	You query only what you need (e.g., only `notes`)
Custom keyPath per store	`users` may use `id`, `settings` use `key`
Easier migrations	You can upgrade one store without affecting others

Decision Point	Recommendation
Clearly different data types	Use multiple stores
Same structure, just different categories	Use one store with a `type` field & index
Need to query across stores	Use a single store or denormalize
Need to version or migrate independently	Use separate stores

interview

Can you separate concerns using multiple object stores efficiently? When would you avoid that?

Can you answer this question?

1 Answers

When You Should Use Multiple Object Stores

Use Case: Clearly Different Entities

Example:

Benefits:

When to Avoid Too Many Object Stores

Avoid if:

Example:

Efficient Multi-Store Use Tips

1. Use Indexes Instead of Separate Stores for Categories

2. Avoid Unnecessary Transactions

3. Batch Related Data Together (if tightly coupled)

Rule of Thumb

Example Design: Multi-Store

Conclusion