Migrating 50 Production Databases to Aurora with Under 3 Minutes of Downtime

Thu, 10 Sep 2026 00:00:00 +0000

Over about two years, we migrated around 50 production databases from on-premises MySQL to AWS Aurora. The largest were multi-terabyte, tier-0 systems with 24/7 write traffic. Most cutovers took under 3 minutes of downtime.

That number is not the result of careful clicking during a maintenance window. It’s the result of treating the downtime budget as a design input: once “3 minutes” is a requirement rather than a hope, every downstream decision — replication topology, rehearsal gates, connection draining, DNS weights — is forced into a specific shape. This post is the methodology that fell out of that constraint, plus what actually bit us along the way.

Vitess vs Aurora: Making the Right MySQL Scaling Decision

Fri, 20 Dec 2024 00:00:00 +0000

If you’ve outgrown single-instance MySQL, you’re facing an uncomfortable choice: build custom sharding logic into your application, migrate to a different database system, or adopt a clustering solution like Vitess.

Here’s the short version, so you know whether to keep reading: after running Vitess in production for 3 years, we migrated off it — to Aurora. Not because Vitess failed us, but because the one capability that justified its operational cost (horizontal write sharding) turned out to be a capability we never actually needed. If your write traffic genuinely exceeds what one large primary can take — think tens of thousands of writes per second sustained, not bursts — Vitess is likely your answer and this post will tell you what operating it really costs. If you’re below that bar, Aurora is almost certainly the better decision, and this post will tell you why.

Database on cloudplz

Migrating 50 Production Databases to Aurora with Under 3 Minutes of Downtime

Vitess vs Aurora: Making the Right MySQL Scaling Decision