Every Ceiling at Once: How Canva Left MySQL for DynamoDB

The media service's shape explains its scale. For each media it stores the ID, the owning user, library membership, external source information, status, a large set of content metadata (title, artist, keywords, color), and references to the underlying files. Reads dominate writes, media are rarely changed after creation, and most reads are for recently created media, with the stock library the exception. Like most of Canva's services, it began as a thin layer over MySQL on RDS, scaled first with bigger instances, then with slightly-stale reads from MySQL replicas.

The cracks arrived through the schema. Changes on the largest media tables began taking days, and MySQL's built-in way of altering tables (online DDL) slowed performance so badly it couldn't run under user traffic at all. GitHub's gh-ost, an open-source migration tool, restored safe online schema changes. Then the walls arrived in formation:

• MySQL 5.6's replication had a hard rate limit, capping how fast writes could reach the read replicas.
• Even with gh-ost, schema migrations eventually stretched to six weeks, blocking feature releases.
• The RDS storage volume was nearing its 16TB limit, and each size increase measurably raised I/O latency, which led to slow user requests.
• Serving production traffic needed a hot cache in memory, so restarts and upgrades meant accepting downtime.
• Because the RDS instances were built from snapshots using the older ext3 disk format, MySQL table files were hard-capped at 2TB.

NOT ONE WALL, MANY AT ONCE

By mid-2017 the number of Canva media approached one billion and was still growing exponentially. The team was clear about its constraint: it strongly preferred incremental steps that kept everything scaling, rather than betting the company on one unproven technology. That meant MySQL had to keep growing while its replacement was investigated, prototyped, and proven against the real workload.

Runway came first, through a series of temporary fixes that each bought more time on MySQL:

• The most-often-changed part of the schema, the content metadata, moved into a single JSON column the service managed itself, so changing it no longer needed a slow schema change.
• Tables were denormalized (related data folded together) to cut lock contention and joins, foreign-key checks were dropped, and repeated values like S3 bucket names were shortened.
• At the very end, a deliberately simple scheme split media by ID range across servers, dodging the 2TB file limit and the replication cap. It was tuned for the common case, looking up media by ID when loading a design, and paid for it with slow scatter-gather (asking every server) on everything else, like listing a user's media.

In parallel, the team investigated and prototyped long-term options. With a short runway, a preference for managed services, earlier experience running simpler DynamoDB workloads, and a working prototype, DynamoDB became the tentative target. It still had to be proven against the real workload, with a migration that would touch no user and switch over with zero downtime.

The replication design is the post's quiet masterpiece. Instead of writing every change to both MySQL and DynamoDB at once, replaying an ordered log, or using AWS's migration service, Canva put tiny messages on a queue (SQS). Each recorded only that a given media was created, updated, or read, never the change itself. A worker takes a message, reads that media's current state from the MySQL primary, and writes it to DynamoDB if needed. Because the state is always re-read fresh from the source of truth, the messages can be reordered, retried, paused, or slowed with no effect on correctness, and nobody has to write a fragile log parser.

THE QUIET MASTERPIECE

Two queues set the priority: creates and updates on a fast queue, reads on a slow one, with workers emptying the fast queue first, so the data that mattered most stayed the most up to date. To copy the older media, a background scan went through them newest-first (matching how they are read), adding each to the slow queue only when that queue was nearly empty, so it never overloaded anything. This took load off MySQL as soon as the busiest media had moved.

MOVE THE HOT DATA FIRST

Proof ran in production. A dual-read comparison served every read from MySQL while checking it against the DynamoDB version, until the replication bugs it surfaced were fixed. Then slightly-stale single-media reads moved to DynamoDB, with a MySQL fallback for the few not yet copied. Some queries don't ask for a media by ID, like 'all media owned by a user'. Those couldn't be answered from DynamoDB until every media had been copied, so they stayed on MySQL until the scan finished, then switched the same careful way.

The write cutover was the riskiest step, and it was wrapped accordingly. New code used all-or-nothing writes (either the whole change is saved or none of it is) and conditional writes to keep the same guarantees as before. Around it went a full test matrix on both the old and new versions, local and end-to-end runs, and a checklist tied to a flag that could send reads back to MySQL within seconds, rehearsed through development and staging. The production cutover was seamless: no downtime, no errors, and median and p95 (the slow-request measure) latency both improved.

THE WHOLE MIGRATION, IN ORDER

The lessons are printed as commands: be lazy (know your access patterns, migrate the busy data first), do it live, and test in production. Five years on, monthly active users have more than tripled, DynamoDB has autoscaled through all of it at lower cost than the RDS it replaced, and the service holds more than 25 billion media with 50 million arriving daily.