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, owning user, library membership, external source information, status, an extensive set of content metadata — title, artist, keywords, color information — and references to the underlying files. Reads dominate writes, media are rarely modified after creation, and most reads target recently created media, with the stock library as the exception. Like most of Canva's resource-oriented services, it began as a thin layer over MySQL on RDS, scaled first vertically with larger instances, then horizontally with eventually consistent reads served from MySQL replicas.

The cracks arrived through the schema. Changes on the largest media tables began taking days; MySQL's online DDL degraded performance so severely it couldn't run under user traffic at all. GitHub's gh-ost restored safe online migrations — a cross-company loan the post credits by name — and then the walls arrived in formation: hard limits on MySQL 5.6's replication rate imposed a ceiling on write throughput to the read replicas; even gh-ost migrations eventually stretched to six weeks, blocking feature releases; the RDS EBS volume approached its then-16TB maximum, and each size increase measurably raised I/O latency, feeding straight into user-facing tail latencies; serving production traffic required a hot buffer pool, so instance restarts and version upgrades meant accepting downtime; and because the RDS instances had been created from snapshots carrying an ext3 filesystem, MySQL table files were hard-capped at 2TB — the same limit the post notes took Instapaper down.

By mid-2017 the count of Canva media approached one billion and was increasing exponentially. The team's constraint on any way out is stated plainly: a strong preference for incremental approaches that would let them keep scaling without betting everything on a single unproven technology choice — which meant the existing MySQL system had to keep growing while its replacement was investigated, prototyped, and proven against the real workload.

Runway came first. The most commonly modified part of the schema — media content metadata — moved into a JSON column whose schema the media service managed itself, taking the hottest churn out of DDL's reach. Tables were denormalized to reduce lock contention and joins; repeated content like S3 bucket names was removed or encoded shorter; foreign key constraints were dropped; the media import path was reworked to issue fewer metadata updates. At the end of the MySQL era, a deliberately simple application-sharding scheme split media by ID range across primaries — dodging the 2TB file limit and the replication ceiling — optimized for the dominant access pattern, lookup by ID when loading designs, and paying for it with inefficient scatter-gather on everything else, like listing a user's media. In parallel, alternatives were investigated and prototyped; with a short runway, a preference for managed services, prior experience running simpler DynamoDB workloads, and a working prototype, DynamoDB became the tentative target — pending proof against the actual workload and a migration that would touch no user and cut over with zero downtime.

The replication design is the post's quiet masterpiece. Rather than dual writes, an ordered log, or AWS DMS, Canva enqueued content-free messages to SQS recording only that a particular media was created, updated, or read — never the update's content. A worker receives the message, reads the media's current state from the MySQL primary, and writes DynamoDB if needed. Because state always comes fresh from the source of truth, messages can be arbitrarily reordered, retried, paused, or slowed with no correctness consequence. Two queues turned the design priority-aware: creates and updates on a high-priority queue, reads on low, workers draining high before touching low — tuning freshness exactly where writes made staleness dangerous. A scanning process walked the remaining backlog most-recent-first, in line with the read pattern, feeding the low-priority queue under backpressure: the scan advanced only while that queue ran approximately empty, shedding load from MySQL as early as the hot data allowed.

Proof ran in production. A dual-read comparison checked DynamoDB results against MySQL until the replication bugs it surfaced were fixed; then eventually consistent single-media reads moved to DynamoDB with MySQL fallback for stragglers. Queries that don't name an ID — all media owned by a user — structurally couldn't serve until the scan completed, and got the same dual-read treatment afterward. The write cutover, named the riskiest step, required new service code using transactional and conditional writes to preserve the previous implementation's contracts, and was surrounded accordingly: integration tests run against both migrated and DynamoDB-native media, the full suite run against both implementations, local and end-to-end passes, a run book keyed to a flag system that could return reads to MySQL within seconds, rehearsed through development and staging. Production cutover was seamless — no downtime, no errors, and a visible improvement in median and p95 latency. The lessons are printed as imperatives: be lazy (know your access patterns; migrate the commonly accessed first), do it live, test in production. Five years on, monthly actives have more than tripled, DynamoDB has autoscaled through it at lower cost than the RDS clusters it replaced, and the service holds more than 25 billion media with 50 million arriving daily.