Bun sqlite3 transaction rollback does not revert schema changes after implicit commit

Answer to the exact question

In SQLite, CREATE, ALTER, and DROP are fully transactional. A ROLLBACK inside an open transaction will undo those schema changes. If you see the schema persisting after a rollback in Bun, the transaction was not actually active when the DDL ran, or it ran on a different connection. The Bun module does not need a blanket warning – the issue is usually in how the transaction is started or scoped.

Why the rollback appears to ignore DDL

• Transaction not open – Bun’s db.transaction() helper creates a new connection for the callback. If the DDL is executed outside that callback, it runs in autocommit mode.
• Different connection – Each db.exec() call can open its own connection if not passed the same Connection object. Schema changes are visible immediately on the main database file.
• Implicit commit by SQLite – Only a handful of statements (e.g., VACUUM, ATTACH) force an implicit commit. Standard DDL does not.

What SQLite actually does

Standard SQLite DDL is transactional. A quick test in plain SQLite:

sqlite3 test.db
BEGIN;
CREATE TABLE t(id INTEGER PRIMARY KEY);
ROLLBACK;
SELECT name FROM sqlite_master WHERE type='table';
-- No rows returned – the table was rolled back.

Thus, the failure to revert schema changes is not a SQLite bug but a usage issue.

Practical steps to diagnose your Bun code

1. Confirm the transaction is active:

   await db.transaction(async (trx) => {
     // All statements here share the same connection
     await trx.exec('CREATE TABLE foo(id INTEGER)');
     // ...
   });

2. Make sure DDL runs inside the callback – Do not call db.exec() after the transaction callback returns.
3. Verify the same connection – Pass the transaction object to every statement:

   await trx.exec('INSERT INTO foo(id) VALUES(1)');

4. Test with raw SQLite – Create a tiny script that uses sqlite3 directly to rule out Bun‑specific behavior.
5. Check for non‑transactional statements (e.g., VACUUM) that might be executed inadvertently.

Should Bun warn or isolate?

Because SQLite already handles transactional DDL, a blanket runtime warning would be misleading. A better approach is:

• Provide a helper API that flags statements known to be non‑transactional (VACUUM, ATTACH, DETACH, some PRAGMAs).
• Document that DDL is safe inside db.transaction() when executed on the same connection.
• If a future version of Bun’s transaction helper were to automatically wrap DDL in a SAVEPOINT, it would be unnecessary for standard DDL but could help with nested transaction semantics.

One missing detail that changes the recommendation

Do you use Bun’s db.transaction() helper, or are you manually issuing BEGIN / COMMIT statements? The answer determines whether the transaction is truly active for your DDL.