Concurrent Migrations

Monospace serializes all schema-mutating operations on a per-project basis using an in-process write lock. Each project holds its own lock, so migrations on different projects can proceed in parallel while mutations on the same project are queued. Pending migrations are applied automatically at startup: the system first persists the updated schema inside a database transaction, then applies the changes to the external datasources. If any step fails, the system transaction is rolled back and both sides remain in sync at the previous version.

The Pitfall

The write lock only coordinates within a single process. If you somehow end up running multiple Monospace instances against the same system database, each instance will independently attempt to apply pending migrations at startup. Two instances may try to create the same table or add the same column at the same time, causing one or both to fail startup or enter an inconsistent state.

Mitigation

Make sure only one Monospace instance is running against a given system database at any time. If you need to restart or upgrade, stop the existing instance before starting the new one.