Limits of Sequelize Nested Transaction Commit Behavior

Nested Transactions in Sequelize

The goal is to clarify how Sequelize’s nested transaction API interacts with outer transactions when committing or rolling back changes. In Sequelize, a nested transaction is implemented via a database savepoint: starting a new transaction inside an existing one creates a savepoint that can be released or reverted independently.

Constraints arise from dialect support—PostgreSQL, MySQL, MariaDB, and MSSQL all honor savepoints, whereas dialects lacking this feature treat nested calls as no‑ops and throw errors. Additionally, the semantics of commit and rollback differ: committing a nested transaction only releases its savepoint, while rolling back a nested transaction undoes operations performed after that savepoint but leaves the outer transaction’s state untouched.

Unresolved behavior: it is unclear how the outer transaction’s final commit interacts with prior nested commits or rollbacks across all dialects, and whether Sequelize automatically cleans up savepoints on outer transaction commit or if manual cleanup is required.

Specific Questions

• What is the exact effect of committing a nested transaction on the state of its outer transaction across supported dialects?
• Under what circumstances does rolling back a nested transaction influence the outer transaction’s ability to commit?
• Does Sequelize automatically release or keep savepoints when an outer transaction is committed, and does this vary by dialect?