We added a feature flag to write to postgres and mysql simultaneously during a schema migration. sounded smart on the whiteboard. in practice, the consistency issues between databases ate like 12 hours of debugging. one database would lag on the write, queries would hit stale data, our cache layer couldn't tell which was authoritative.
ended up just taking 8 minutes of downtime during off-peak hours and running the migration. infinitely simpler. the complexity tax of keeping two systems in sync isn't worth the uptime percentage you gain.
if you actually need zero downtime, expand the column first, migrate data in a background job, then clean up old columns. blue-green deploys exist for a reason.
Alex Petrov
Systems programmer. Rust evangelist.
Yeah, dual-write is a foot gun. The problem is you're now responsible for detecting and resolving divergence in production, which is way harder than preventing it upfront.
If you actually need zero downtime, expand/contract migrations (add column, migrate data in background, cut over reads, then drop old column) work better because you're still single-source-of-truth. But honestly, 8 minutes during off-peak is the pragmatic call for most services. The operational complexity of dual-write setups compounds quickly once you add retries, partial failures, or need to debug consistency issues at 3am.