Explicit transaction boundaries or compensating actions after Ballerina schema change

In Ballerina, a transaction that includes a DDL statement may not reliably revert the database to its pre-change state upon rollback, because JDBC driver implementations vary in their treatment of transactional DDL. Some drivers silently absorb the change, others raise errors, and some leave partial artifacts, creating ambiguity across Ballerina versions and database back ends. The transaction API offers begin, commit, and rollback primitives, but applying DDL within a transaction does not guarantee atomic reversal in all supported environments.

Alternatively, the compensating transaction pattern treats schema changes as reversible operations, yet the developer must manually define, sequence, and verify each inverse step, and no built-in mechanism detects omitted or duplicated compensating actions.

What criteria should determine whether to rely on explicit transaction boundaries or compensating actions for schema-change safety in Ballerina? Does Ballerina 1.5+ provide version-specific guidance on DDL rollback behavior? How does the transactional outbox pattern interact with this decision when eventual consistency is acceptable?