Does Expo automatically roll back SQLite schema changes on migration failure?

Direct answer

No. Expo's expo-sqlite does not automatically roll back schema changes when a migration fails. If you execute each DDL statement individually with execAsync or runAsync, SQLite runs them in autocommit mode and persists them immediately. A later failure does not undo earlier CREATE TABLE, ALTER TABLE, or CREATE INDEX calls.

Confirmed facts vs. likely explanation

Confirmed behavior: The module provides withTransactionAsync (and withTransactionSync). These wrappers begin a transaction, commit when the callback resolves, and roll back when the callback throws. Because SQLite treats DDL as transactional, schema changes made inside the wrapper are reverted on error.

Likely explanation: Expo does not insert an implicit transaction around every database call. The absence of automatic rollback for individual statements is a consequence of exposing SQLite's default autocommit behavior rather than a deliberate migration framework.

Safe migration pattern

1. Read the current schema version with PRAGMA user_version.
2. Call withTransactionAsync and pass a single callback that runs every migration step in order.
3. Inside the callback, execute all schema changes with execAsync or runAsync. Do not call those methods outside the wrapper.
4. After the last statement succeeds, update the version: PRAGMA user_version = <new_version>.
5. Let the callback return normally to commit, or throw to trigger the rollback.

await db.withTransactionAsync(async () => {
  await db.execAsync(`CREATE TABLE ...`);
  await db.execAsync(`ALTER TABLE ...`);
  await db.execAsync(`PRAGMA user_version = 2`);
});

Caveats and verification

• Do not mix calls. An execAsync issued outside withTransactionAsync commits independently and cannot be rolled back by the surrounding transaction.
• Nested transactions vary. Depending on your Expo SDK version, nested withTransactionAsync blocks may use savepoints or may be rejected. Verify the semantics for your installed version before relying on nesting.
• Crash recovery is not Expo rollback. If the process is killed mid-transaction, SQLite's journal or WAL restores consistency on the next open. That is engine-level crash recovery, not an application-managed migration rollback.
• Non-transactional commands. Operations such as VACUUM are not transactional and will not be undone by a rollback.

To confirm the behavior in your project, create a table, then throw an error inside withTransactionAsync, and query sqlite_master to verify the table is absent. Repeat the same test without the wrapper to observe that the table persists.

Note: Because exact API availability and nesting semantics can change between Expo SDK releases, treat the above as a conservative pattern and check the expo-sqlite documentation for your installed version before shipping.