IndexedDB
Slap yourself if
You think IndexedDB is just async localStorage or assume transactions behave like database transactions you know.
Why this exists
Because IndexedDB is routinely blamed for slowness or data loss when the real issues are event-loop coupling, transaction lifetimes, and quota semantics engineers never internalized.
Mental model
IndexedDB is an event-loop–driven, transactional object store with strict lifetime rules and browser-managed durability. You don’t control threads, scheduling, or flushing — you negotiate with them.
- Operations are executed off the main thread but coordinated through the event loop.
- All reads and writes must occur inside an active transaction scope.
- Transactions auto-close when the call stack and microtasks drain.
- Durability and flushing are browser-managed and opaque.
- Using a transaction across async gaps and getting silent failures.
- Overusing readwrite transactions and blocking other work.
- Assuming writes are durable immediately after success callbacks.
- Treating object stores like relational tables.
IndexedDB is an asynchronous, transactional object store where transaction lifetime is tied to the event loop, not explicit commits.
- Calls it async localStorage.
- Assumes transactions persist across awaits.
- Talks about tables and joins.
- Ignores quota and eviction.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.