Transactional Rollback versus Snapshot Restore for DDL Safety in Cucumber-JVM

The goal is to maintain database schema consistency after a Cucumber scenario that includes data-definition-language statements, given that most relational databases issue an implicit commit when DDL executes. Because Cucumber-JVM's @Transactional annotation only rolls back data-manipulation operations, schema changes such as ADD COLUMN persist beyond the scenario boundary, creating a mismatch between expected and actual database state.

A concrete constraint arises from the documented behavior that transactional rollback mechanisms in common test harnesses do not revert DDL, while alternative schema snapshot/restore approaches introduce runtime overhead and may complicate parallel execution if isolation per thread is not guaranteed. This trade-off forces a design decision between relying on manual DDL cleanup and adopting a restore mechanism that may impact test suite throughput.

What factors determine whether a specific database vendor treats DDL as transactional? How does a schema snapshot/restore workflow interact with Cucumber's scenario-level hooks when tests run in parallel? Which approach provides the lowest persistent schema drift with acceptable impact on test execution speed?