Managing database schema changes without downtime
Having no-down-time when doing migrations is not an easy topic.<p>> These defer drops will happen at least 30 minutes after the particular migration referenced ran (in the next migration cycle), giving us peace of mind that the new application code is in place.<p>Pretty much that's what I've seen before. You do series of deployments + migration scripts.<p>Usually :<p>- Migrate with backward-compatible modifications of the schema<p>- Release application logic that takes advantage of both migrated / to-be-deprecated tables<p>- Possible extra migration to sync the new / old tables.<p>- Release application logic that stops using the to-be-deprecated tables.<p>- Migrate with destructive modifications to remove the old table.<p>Usually that's a huge complicated process which might be replaced with one migration and a few minutes of downtime. Sadly some companies can't afford it, so they do such changes with weeks planing.<p>I usually vote for having some planned non-working-hours downtime.