# Choose a schema migration workflow

Coordinator DB does not document a product-specific schema migration tool. Choose a client workflow that executes the supported SQL, records which migration completed and can verify the resulting schema. A tool's generic SQL support is not proof that its generated dialect is compatible.

## Test the generated statements

Review each migration against the statement reference. Add, drop and rename columns use `ALTER TABLE`; a type change requires a replacement table and explicit conversion. Primary keys, defaults and foreign-key behavior deserve deliberate validation. `CREATE TABLE AS SELECT` copies projected declarations and rows but not the source constraints.

Use an isolated database to run the migration forward from the real starting schema. Confirm metadata and representative application queries afterward. A migration marked “applied” is weak evidence if the schema check was skipped.

## Keep the execution boundary clear

A native connection can retain transaction state. An HTTP transaction must begin and commit in one request. Separate HTTP calls cannot continue the same open transaction. Store a migration identifier only after its intended SQL unit succeeds, and reconcile ambiguous responses before rerunning.

For destructive or replacement changes, preserve an independent copy and test the rollback decision with the same data boundary. Do not assume every change can be undone after new application writes.

See [SQL statements](https://coordinatordb.com/docs/reference/statements), [ALTER columns](https://coordinatordb.com/docs/reference/statements/alter/column) and [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions).