Schema Migration Lock Behavior During Partial Rollback Attempts

Goal

Determine whether SurrealDB's migration lock provides sufficient isolation to safely revert a schema change that fails mid-execution.

Constraints and uncertainty

Migrations run as a sequence of DDL statements without a built-in atomic transaction boundary. If a failure occurs partway through, the database remains in an intermediate state. The documentation mentions a migration lock that prevents concurrent schema changes, but it does not specify whether that lock also blocks ordinary write operations while a rollback is being attempted.

Without guaranteed isolation, a rollback script could race with live traffic, leaving the schema in an inconsistent state or causing write failures that are difficult to diagnose.

Questions

1. Does the migration lock acquire an exclusive lock that also pauses all data-write operations for the affected tables?
2. If the lock is schema-only, what is the recommended pattern for coordinating a manual inverse migration without downtime?
3. Is there a plan to expose a "schema transaction" flag that would wrap the entire migration in a single atomic unit?