Canva's Creators Monetization team had to split over 1 TB of royalty-tracking data off a shared RDS instance without dropping a single usage event — because every dropped row is a mispaid creator.

The Canva Creators program had grown to over 400,000 high-quality templates and a 100% year-over-year increase in monthly active users — more than 100 million MAUs whose template usage the Creators Monetization team tracks to calculate royalty payments. All of that lived in a single AWS RDS instance holding hundreds of gigabytes of relational data. As part of splitting a monolithic system into smaller independent services, the team could extract the code and infrastructure cleanly, but they still had to split the giant shared store of data itself.

The stakes made this more than a routine migration. This data determines what creators get paid.

The migration moved 8 tables holding over 1 TB of data in total, excluding indexes. For the largest table, the team only needed the last 100 GB of rows — older data was archived rather than migrated, which kept the move smaller than the raw table size suggested.

The whole thing — preparation, the migration itself, fixing the problems that came up, and verification — took about a day. AWS DMS’s built-in validation feature confirmed the data had moved correctly, with no loss or mutation, and users never saw an interruption while reading from the old service.

Crossing the gap relied on a shadowing approach much like a blue-green deployment: a new service ran alongside the old one so its behavior could be verified without touching live production. The cutover sequence was to pause data processing in the new service while users kept reading from the old database, snapshot the old database, run a point-in-time migration, replay the messages that had queued up in the meantime and merge them with the migrated data, then switch user traffic over.

The reason pausing was safe is the queue. Canva uses AWS SQS, which holds messages for up to 14 days and guarantees at-least-once delivery — enough runway to do the point-in-time copy without losing events. Duplicates that at-least-once delivery might introduce were absorbed by an existing deduplication stage, which already counts a usage only once per user per design.

For the copy itself, the team evaluated four options: SQL dump and batch inserts (kept as a last resort because of the automation and security effort), trimming a copy of the source database (rejected because they needed both access-management changes and storage downsizing), row-by-row replication via workers and SQS (too much effort without a schema change to justify it), and AWS DMS. DMS won on its feature set — source filters to move only recent data, automated table truncation, transformation rules to rename schemas, and the validation feature to prove nothing was lost.

The migration started smoothly and then set off alarms: the new service’s primary RDS instance hit performance problems from a lack of burst capacity, and the DMS replication slowed to a crawl. DMS wasn’t the culprit. Checking IOPS and CPU, the team found the target instance was already doing far more write operations than the source and burning CPU on intensive indexing — the same indexes that made queries fast were now fighting the migration for resources.

The fix had two parts. They dropped the indexes and recreated them after the migration, which immediately improved the burst balance and let replication run to completion faster. And they upgraded the target’s storage to gp3, which let them scale IOPS independently of storage size with no downtime — though it took up to 24 hours to take effect. They ended up not needing all that extra IOPS during the copy, but it did speed up rebuilding the indexes afterward, which took a couple of hours.

Their honest reflection: load testing beforehand would have surfaced the burst-capacity problem earlier, since dev and staging didn’t hold enough data to reproduce the production workload. Good observability and alerting were what let them catch and diagnose the slowdown quickly. And they echo AWS’s own advice — be aware of your table index sizes and either drop large indexes before a migration or raise IOPS capacity ahead of time, so indexing doesn’t starve the migration of resources.

The design decision they credit most is upstream of DMS entirely: having an SQS queue in the architecture is what made a clean, zero-downtime split possible without live change capture.

A bulk data migration is a capacity-planning problem wearing a correctness problem’s clothes — the copy logic was sound, and the crisis came from the target instance having no burst balance for writes and indexing.