NestJS‑TypeORM Integration: Should Migrations Execute Inside Automatic Transactions?

The goal is to guarantee that a schema‑change migration can be rolled back completely when it fails, preserving database consistency in a NestJS application that relies on TypeORM for data access.

By default TypeORM’s Migration interface runs SQL statements outside any NestJS‑managed transaction, so developers must manually start, commit, or roll back a QueryRunner transaction inside the up/down methods. The NestJS documentation does not define a default behavior, leaving the decision to the implementer and creating variability in error‑handling practices.

An unresolved design question is whether NestJS should provide a higher‑level wrapper (e.g., a MigrationService) that automatically encloses migrations in a transaction and handles compensation on failure, thereby reducing boilerplate and the risk of missed error handling.

Should NestJS ship a built‑in MigrationService that wraps migrations in a transaction? What are the trade‑offs of automatic transaction wrapping versus manual handling? How would such a wrapper interact with existing custom QueryRunner usage and third‑party migration libraries?