---
title: "How do you handle version changes in IndexedDB?"  
description: "How do you handle version changes in IndexedDB?"  
author: "Ponu Maurya"  
published: 2025-07-03  
updated: 2025-07-03  
canonical: https://www.mindstick.com/interview/34310/how-do-you-handle-version-changes-in-indexeddb  
category: "database"  
tags: ["database", "indexeddb"]  
reading_time: 3 minutes  

---

# How do you handle version changes in IndexedDB?

Handling **version changes** in **IndexedDB** is a critical part of managing schema upgrades (like adding new object stores or indexes).

### How Versioning Works in IndexedDB

Every IndexedDB database has a **version number** (default is `1`). A version change triggers the `onupgradeneeded` event. You can only modify the **database structure** (create/delete object stores, indexes, etc.) inside this event.

### Version Change Flow

```javascript
const request = indexedDB.open("MyDatabase", 2); // Version 2 triggers upgrade

request.onupgradeneeded = function (event) {
    const db = event.target.result;
    const oldVersion = event.oldVersion;
    const newVersion = event.newVersion;
    console.log(`Upgrading from version ${oldVersion} to ${newVersion}`);

    if (oldVersion < 1) {
        const store = db.createObjectStore("users", { keyPath: "id" });
        store.createIndex("name", "name", { unique: false });
    }

    if (oldVersion < 2) {
        const store = db.transaction.objectStore("users");
        store.createIndex("email", "email", { unique: true });
    }
};

request.onsuccess = function (event) {
    const db = event.target.result;
    console.log("Database opened successfully.");
};

request.onerror = function (event) {
    console.error("Database error:", event.target.error);
};
```

### Key Points

| Feature | Explanation |
| --- | --- |
| `indexedDB.open(name, version)` | Pass a **higher version number** to trigger schema changes. |
| `onupgradeneeded` | Only place you can create/remove object stores and indexes. |
| `event.oldVersion` | The version you’re upgrading **from**. |
| `event.newVersion` | The version you’re upgrading **to**. |
| Safe Upgrades | Always use version checks like `if (oldVersion < x)` to support multi-step upgrades. |

### Best Practice

- Always **increment the version number** when changing schema.
- Never use `put/add/delete` [inside `onupgradeneeded`](https://www.mindstick.com/interview/34305/what-happens-during-the-onupgradeneeded-event) unless necessary — structure only.
- Use **feature flags or version guards** to keep upgrades backward-compatible.

## Answers

### Answer by Ponu Maurya

Handling **version changes** in **IndexedDB** is a critical part of managing schema upgrades (like adding new object stores or indexes).

### How Versioning Works in IndexedDB

Every IndexedDB database has a **version number** (default is `1`). A version change triggers the `onupgradeneeded` event. You can only modify the **database structure** (create/delete object stores, indexes, etc.) inside this event.

### Version Change Flow

```javascript
const request = indexedDB.open("MyDatabase", 2); // Version 2 triggers upgrade

request.onupgradeneeded = function (event) {
    const db = event.target.result;
    const oldVersion = event.oldVersion;
    const newVersion = event.newVersion;
    console.log(`Upgrading from version ${oldVersion} to ${newVersion}`);

    if (oldVersion < 1) {
        const store = db.createObjectStore("users", { keyPath: "id" });
        store.createIndex("name", "name", { unique: false });
    }

    if (oldVersion < 2) {
        const store = db.transaction.objectStore("users");
        store.createIndex("email", "email", { unique: true });
    }
};

request.onsuccess = function (event) {
    const db = event.target.result;
    console.log("Database opened successfully.");
};

request.onerror = function (event) {
    console.error("Database error:", event.target.error);
};
```

### Key Points

| Feature | Explanation |
| --- | --- |
| `indexedDB.open(name, version)` | Pass a **higher version number** to trigger schema changes. |
| `onupgradeneeded` | Only place you can create/remove object stores and indexes. |
| `event.oldVersion` | The version you’re upgrading **from**. |
| `event.newVersion` | The version you’re upgrading **to**. |
| Safe Upgrades | Always use version checks like `if (oldVersion < x)` to support multi-step upgrades. |

### Best Practice

- Always **increment the version number** when changing schema.
- Never use `put/add/delete` [inside `onupgradeneeded`](https://www.mindstick.com/interview/34305/what-happens-during-the-onupgradeneeded-event) unless necessary — structure only.
- Use **feature flags or version guards** to keep upgrades backward-compatible.


---

Original Source: https://www.mindstick.com/interview/34310/how-do-you-handle-version-changes-in-indexeddb

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