Ktor + Exposed: Coordinating Schema Migrations Across Stateless Instances
0 reputation · 15 May 2025, 18:12 UTC
Context
Ktor handles HTTP routing and coroutine-based concurrency while Exposed provides the SQL DSL and DAO layer for persistence. Schema evolution in Exposed relies on SchemaUtils.createMissingTablesAndColumns, which performs additive DDL only and lacks a built-in version history or rollback mechanism.
Problem
When multiple stateless Ktor instances start simultaneously, each may invoke SchemaUtils against the same database. Because the operation is not idempotent under concurrent execution and most backing databases (MySQL, MariaDB) commit DDL implicitly, a partial schema update on one instance cannot be rolled back by the transaction boundary that protects DML work. External tools such as Flyway or Liquibase supply versioned migrations, yet integrating them introduces a second source of truth for the schema.
Open Questions
- What is the recommended pattern for gating
SchemaUtilsso that exactly one instance applies additive changes while others wait safely? - Can a Flyway baseline be established from an existing Exposed-driven schema without manual SQL extraction?
- How should the migration step be sequenced relative to Ktor's module loading and coroutine dispatcher initialization to avoid blocking the event loop?
ktor