---
title: "What’s the performance impact of using indexes vs linear scans in IndexedDB?"  
description: "What’s the performance impact of using indexes vs linear scans in IndexedDB?"  
author: "Harry"  
published: 2025-07-07  
updated: 2025-07-07  
canonical: https://www.mindstick.com/interview/34326/what-s-the-performance-impact-of-using-indexes-vs-linear-scans-in-indexeddb  
category: "IndexedDB"  
tags: ["indexeddb"]  
reading_time: 4 minutes  

---

# What’s the performance impact of using indexes vs linear scans in IndexedDB?

Using **indexes** vs **linear scans** in IndexedDB has **massive performance implications**, especially as your dataset grows. Here’s a breakdown:

## Indexed Lookup vs Linear Scan

| **Factor** | **Indexed Lookup** | **Linear Scan** |
| --- | --- | --- |
| **Time Complexity** | O(log n) (B-tree traversal) | O(n) (must inspect all records) |
| **Performance (10K items)** | ~1–5ms | 100ms–1000ms+ (or much worse) |
| **Memory Usage** | Minimal (returns only matches) | High (may load all into memory) |
| **Scalability** | Excellent | Degrades rapidly |
| **Browser Optimization** | Fully optimized path | Least optimized |

## Real-World Example

Suppose you have **10,000 users** and want to find the one with email = `x@example.com`.

### 1. With Index (`email` indexed)

```javascript
await db.users.where('email').equals('x@example.com').first();
```

✅ Indexed B-tree lookup → Fast (~milliseconds)

### 2. Without Index

```javascript
await db.users.toArray().then(users => users.find(u => u.email === 'x@example.com'));
```

❌ Loads **all 10,000** users into memory → Slow + memory-heavy

## Benchmarks (Approximate)

| Dataset Size | Indexed Query | Linear Scan |
| --- | --- | --- |
| 1,000 items | ~1–2ms | ~20–50ms |
| 10,000 items | ~2–5ms | ~100–300ms |
| 100,000 items | ~5–10ms | 1–3 seconds |

*(Browser- and hardware-dependent; rough estimates)*

## Why Indexed Queries Are Faster

- IndexedDB uses **B-trees** internally for indexes.
- B-trees allow fast traversal to matching keys without scanning the full store.
- Index-based queries go directly to matching entries or a narrow range.

## Linear Scan Pitfalls

- `.toArray()` retrieves **all records**.
- `.filter()`/`.find()` works **in memory**, not on the IndexedDB level.
- These operations block the main thread longer and consume more memory.

## Best Practices

Always **index fields** that are:

- Frequently filtered (`where()`, `equals()`, `between()`)
- Used for sorting (`orderBy()`)
- Use **compound indexes** for multi-field queries.
- Avoid `toArray().filter()` unless the dataset is tiny.

## Summary

> **Indexed queries in IndexedDB are 10x–1000x faster than linear scans** on large datasets.\
> Always use `.where()` or `.orderBy()` on **indexed fields** for scalable, memory-efficient apps.

## Answers

### Answer by Harry

Using **indexes** vs **linear scans** in IndexedDB has **massive performance implications**, especially as your dataset grows. Here’s a breakdown:

## Indexed Lookup vs Linear Scan

| **Factor** | **Indexed Lookup** | **Linear Scan** |
| --- | --- | --- |
| **Time Complexity** | O(log n) (B-tree traversal) | O(n) (must inspect all records) |
| **Performance (10K items)** | ~1–5ms | 100ms–1000ms+ (or much worse) |
| **Memory Usage** | Minimal (returns only matches) | High (may load all into memory) |
| **Scalability** | Excellent | Degrades rapidly |
| **Browser Optimization** | Fully optimized path | Least optimized |

## Real-World Example

Suppose you have **10,000 users** and want to find the one with email = `x@example.com`.

### 1. With Index (`email` indexed)

```javascript
await db.users.where('email').equals('x@example.com').first();
```

✅ Indexed B-tree lookup → Fast (~milliseconds)

### 2. Without Index

```javascript
await db.users.toArray().then(users => users.find(u => u.email === 'x@example.com'));
```

❌ Loads **all 10,000** users into memory → Slow + memory-heavy

## Benchmarks (Approximate)

| Dataset Size | Indexed Query | Linear Scan |
| --- | --- | --- |
| 1,000 items | ~1–2ms | ~20–50ms |
| 10,000 items | ~2–5ms | ~100–300ms |
| 100,000 items | ~5–10ms | 1–3 seconds |

*(Browser- and hardware-dependent; rough estimates)*

## Why Indexed Queries Are Faster

- IndexedDB uses **B-trees** internally for indexes.
- B-trees allow fast traversal to matching keys without scanning the full store.
- Index-based queries go directly to matching entries or a narrow range.

## Linear Scan Pitfalls

- `.toArray()` retrieves **all records**.
- `.filter()`/`.find()` works **in memory**, not on the IndexedDB level.
- These operations block the main thread longer and consume more memory.

## Best Practices

Always **index fields** that are:

- Frequently filtered (`where()`, `equals()`, `between()`)
- Used for sorting (`orderBy()`)
- Use **compound indexes** for multi-field queries.
- Avoid `toArray().filter()` unless the dataset is tiny.

## Summary

> **Indexed queries in IndexedDB are 10x–1000x faster than linear scans** on large datasets.\
> Always use `.where()` or `.orderBy()` on **indexed fields** for scalable, memory-efficient apps.


---

Original Source: https://www.mindstick.com/interview/34326/what-s-the-performance-impact-of-using-indexes-vs-linear-scans-in-indexeddb

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.