Miricanvas Improves Performance by 50% and Cuts Costs by 30% with Amazon DocumentDB

Miricanvas switched from MongoDB Atlas to Amazon DocumentDB 8.0 to resolve DB bottlenecks in its real-time collaborative design platform.

The existing Atlas environment frequently hit an IOPS cap of about 3,000 IOPS, and write spikes and replication lag occurred when WiredTiger's checkpoint and dirty cache flush overlapped. Using provisioned IOPS for average write workloads was too costly, so the migration was pursued with the goals of resolving the IOPS bottleneck, AWS native integration, and cost optimization.

Before migrating, the team first verified DocumentDB's architecture and its differences from MongoDB. DocumentDB is not a service that simply hosts MongoDB as-is, but rather an Aurora-based MongoDB-compatible engine, and its storage operates as a 6-copy quorum structure spread across 3 AZs. Replicas also read directly from shared storage instead of replicating from the Primary over the network, so replication lag dropped significantly to 2.5ms on DocumentDB vs 37ms on Atlas.

For compatibility verification, the team analyzed production queries directly, loaded development data using mongodump / mongorestore, and checked each one with explain. During this process they cleaned up incompatible areas by downgrading mongotools to 100.9.5, replacing $set aggregate with $addFields, and separating internal $lookup pipelines, and in Spring they used a Custom @Conditional Annotation to branch between MongoDB and DocumentDB environments.

They also checked performance and storage efficiency together. The average document size for DocumentDB 8.0 + zstd was 700B, and for Atlas zstd it was 550B, resulting in a storage difference of about 165GB at 1.1 billion records. However, with the IO-Optimized configuration, IO costs were included in the instance, making operations simpler for large workloads.

In the POC performance test, a k6 stress test was run on a 3x db.r6g.2xlarge configuration.

• Stress QPS: 1,479/s vs Atlas 1,432/s
• avg query latency: 1.7ms vs 1.8ms
• p95 query latency: 4.6ms vs 8.9ms
• Max Replica lag: 25ms vs 300ms

Throughput and average latency were similar, while tail latency and replication lag were better on DocumentDB. Write performance was slightly better on Atlas, but for a real-time editing service, stability and consistency were more important, and the team decided to migrate.

Migration was carried out using AWS DMS. The full dataset was loaded via Full Load, with parallel loading applied at the Task and Thread level, and until the downtime cutover, MongoDB and DocumentDB were kept in sync via CDC. Initially partitions-auto was used, but it didn't yield sufficient throughput, so in the end range type was used with manually set uniform boundary values, completing the load of 1.1 billion records without throughput degradation.

The biggest variable was CDC data loss. As changeStream processing slowed down and exceeded the oplog window, some changes were lost, and due to the schedule, Full Load could not be re-run from scratch. In the end, large collections were replayed using a custom-built CDC pipeline, while the rest were manually recovered by type using ObjectId timestamps, updatedDate, and backup collections.

At cutover time, DB connection strings were managed via AWS Secrets Manager, allowing endpoints to be changed without redeploying the application, and the process was finished with full QA after server restart. The production environment was configured with 3x db.r6g.2xlarge and IO-Optimized (iopt1) storage, with failover recovering in about under 30 seconds.

The final results were as follows.

• p50 response time: 4.2ms → 2.1ms, a 50% improvement
• Replication lag: 37ms → 2.5ms, a 93% reduction
• Infrastructure cost: about 30% savings
• IOPS ceiling: the 3,000 limit resolved

The key lessons are clear. Since DocumentDB is not managed MongoDB, indexes and query strategy must be redesigned, the single Writer's write ceiling must be verified, and DMS CDC must be tested beforehand under production write load. Data audit columns and a backup system serve as the last safety net in case migration fails.