IndexedDB versionchange transaction rollback consistency across browsers

The IndexedDB specification mandates that a versionchange transaction be atomic. If an error occurs during a schema update, the transaction must abort, reverting the database to its previous version and undoing any structural changes made during that session.

Rollback Guarantees

In major browser engines (Blink/Chrome/Edge, Gecko/Firefox, and WebKit/Safari), the versionchange transaction provides high consistency. When the onupgradeneeded event throws an unhandled exception or calls transaction.abort(), the engine is designed to roll back the creation or deletion of object stores and indexes.

However, while the specification is clear, implementation nuances can occur based on how the underlying storage engine (like SQLite) handles the journal. If the browser crashes mid-transaction, there is a theoretical risk of corruption, though modern browsers typically recover by reverting to the last known consistent state upon the next open.

How to Verify Schema Consistency

Because you cannot rely solely on the browser's atomicity for complex migrations, you should implement a verification check within your application logic:

• Pre-migration Snapshot: Before opening the database with a higher version, check the existing object store names using db.objectStoreNames.
• Post-upgrade Validation: In the onsuccess handler of the database open request, verify that the schema matches your expected state.
• Error Handling: Specifically listen for the error event on the transaction itself. If it triggers, assume the migration failed and do not proceed with application-level logic that depends on the new schema.

Example: Safe Migration Pattern

const request = indexedDB.open("MyDatabase", 2);
request.onupgradeneeded = (event) => {
  const db = event.target.result;
  try {
    db.createObjectStore("newStore");
    // Simulate an error to test rollback
    // throw new Error("Simulated failure");
  } catch (err) {
    event.target.transaction.abort();
  }
};

request.onerror = (event) => {
  console.error("Migration failed, database rolled back.", event.target.error);
};

Are you performing data migrations (moving records between stores) or strictly structural changes (creating/deleting stores)?