Indexed DB: The Browser As a Database

As web applications grew more powerful, a hard limitation became obvious:

Simply key-value storage is not enough for serious client-side data.

Applications needed to store large, structured, queryable data, work offline, and do so without blocking the main thread. This is where IndexedDB enters the picture.

IndexedDB turns the browser into client-side database engine.

Why Web Storage APIs Stop Scaling

LocalStorage and SessionStorage are intentionally simple. That simplicity becomes a problem when:

• Data size grows beyond a few megabytes
• Data becomes structured (objects, relationships)
• Queries are needed (search, filter, sort)
• Performance matters (non-blocking I/O)
• Offline-first behavior is required

Key limitations of Web Storage:

• Synchronous API (blocks main thread)
• No indexing or querying
• String-only values
• Poor performance at scale

Modern applications needed something closer to a real database – but inside a browser.

What Is IndexedDB?

IndexedDB is a low-level, asynchronous, NoSQL database built into modern browsers.

Core characteristics:

• Asynchronous (non-blocking)
• Persistent storage
• Object-based (not string-only)
• Indexed queries
• Transactional guarantees

IndexedDB is designed for:

• Large datasets
• Structured data
• Offline applications

IndexedDB Mental Model

If you come from a backend background, think of IndexedDB like this:

Important difference:

• IndexedDB is schema-light, not schema-less.

Core Building Blocks

Database

• Top-level container
• Versioned
• Scoped to an origin

const request = indexedDB.open("AppDB", 1)

Object Stores

Object stores are where data lives.

• Store JavaScript objects
• Each object has a key
• Similar to tables

db.createObjectStore("users", { keyPath: "id" })

Indexes

Indexes allow efficient querying.

store.createIndex("emailIndex", "email", { unique: true })

Without indexes, querying large datasets becomes slow.

Transactions

All operations in IndexedDB happen inside transactions.

Why this matters:

• Data consistency
• Atomic operations
• Error handling

const tx = db.transaction("users", "readwrite")

Asynchronous by Design

IndexedDB is asynchronous for a reason.

Blocking the main thread would.

• Freeze the UI
• Degrade user experience

Asynchronous design allows:

• Smooth UI interactions
• Background data operations
• Large data handling

This makes IndexedDB ideal for serious applications.

Storage Capacity

IndexedDB offers far larger storage than Web Storage.

Typical limits:

• Hunders of megabytes
• Sometimes gigabytes (with permission)

Browsers may:

• Prompt users for permission
• Evict data under storage pressure

Still, IndexedDB is the largest reliable client-side storage.

Common Use Cases

IndexedDB shines in scenarios such as:

• Offline-first applications
• Caching large API responses
• Email clients
• Messaging apps
• Media-heavy applications
• Local search indexes

Any app that feels like a “desktop app” in the browser likely uses IndexedDB.

Why IndexedDB Feels Hard

Many developers avoid IndexedDB because:

• Verbose API
• Event-based patterns
• Boilerplate-heavy setup

This complexity is intentional – it trades simplicity for power and safety.

In practice, developers often use:

• Wrapper libraries (Dexie, idb)
• Abstraction layers

IndexedDB vs Other Storage Mechanisms

IndexedDB is not a replacement – it is a different tool.

When Should You Use IndexedDB?

Use IndexedDB when:

• Data is large
• Data is structured
• Offline usage is required
• Performance matters

Avoid IndexedDB when:

• Data is tiny
• Simplicity is more important than power