Migration Reset or Transaction Rollback: Which Provides Faster, Reliable Test Isolation for Large Knex.js Schemas?

The goal is to establish a repeatable development/test environment that resets the database quickly while guaranteeing schema consistency and data isolation between tests.

For large schemas, rolling back all migrations and re‑applying them (knex.migrate.rollback → knex.migrate.latest) can be time‑consuming, whereas wrapping each test in a transaction (knex.transact) avoids schema changes but depends on driver support for savepoints or nested transactions. A third option—creating a fresh test database or schema per run—eliminates rollback overhead but may consume significant resources in CI pipelines.

Which approach yields the shortest overall test suite runtime for schemas with hundreds of tables? Does transaction‑based isolation reliably prevent data leakage when the underlying driver lacks nested transaction support? Is the provisioning cost of a temporary test database per CI job acceptable compared to the reset cost of migration rollback/latest?