Should Qwik City routeAction$ migrations avoid request-scoped execution?

Question

Can a Qwik City routeAction$ safely trigger a database schema migration, or should migrations remain a deployment-time step? The routeAction$ is a documented server-side mutation primitive that runs within a request lifecycle and can validate input before returning data to the client.

Constraints

Qwik does not manage database transactions, DDL, or migration history. The unresolved decision centers on placement: executing DDL in a request-scoped action couples migration timing to HTTP timeouts, retries, and concurrent replicas. Multiple application replicas make request-triggered DDL riskier unless the migration tool serializes execution across processes.

Key Considerations

A failed action response does not prove the database change was reverted; partial schema states can persist. Qwik City actions can return an explicit failure value through the action's fail helper, letting a client distinguish a rejected request from a successful mutation. A request-triggered migration is only as safe as its idempotency and locking.

Specific Questions

1. Is it feasible to implement idempotent, lock-coordinated migrations within a routeAction$ handler?
2. Should migration status reporting be decoupled from the action's primary mutation responsibility?
3. Which database engines and Qwik adapter combinations provide sufficient transaction safety for request-scoped DDL?