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:
db.createObjectStore("users", { keyPath: "id" });
db.createObjectStore("notes", { keyPath: "id" });
db.createObjectStore("settings", { keyPath: "key" });
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:
{ id: "1", type: "note", content: "..." }
{ id: "2", type: "task", content: "..." }
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
store.createIndex("type", "type");
Then:
store.index("type").getAll("note");
2. Avoid Unnecessary Transactions
Only open a transaction for the store(s) you need:
const tx = db.transaction(["users", "notes"], "readonly");
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 and 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
users/
  - userId (key)
  - name, email
notes/
  - noteId (key)
  - userId (FK), content, tags, updatedAt
settings/
  - key (key)
  - value
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

interview

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

Ponu Maurya

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

Liked By

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