SYSTEM Cited by 2 sources
MySQL¶
MySQL is a widely deployed open-source relational database, typically the default OLTP store for teams that need a familiar SQL engine and strong ecosystem support. It's single-writer, row-oriented, and doesn't horizontally partition itself by default — scaling is by instance size first, then replicas, then manual sharding.
Pattern of appearance in system-design stories¶
MySQL tends to show up as the start-small choice that outgrew its workload shape. The narrative is familiar:
- Launch on MySQL for a workload that's shaped OLTP but has an aggregation tail nobody worried about in v1.
- Aggregation workers use single-threaded sequential scans + per-record DB round-trips; scales as O(N) queries per pass.
- Storage doubles faster than the instance size can be grown without operational pain; shared-instance blast radius grows.
- Move raw events off first (to a horizontally-scaling store like DynamoDB or S3), then move the aggregation workload off entirely to an OLAP warehouse.
Canva's Creators-payment counting pipeline walked this exact path over several years: RDS MySQL, doubling every 8–10 months, reaching several TB, with shared-instance risk driving a split and then the move to Snowflake + DBT. (Source: sources/2024-04-29-canva-scaling-to-count-billions)
Honest assessment from the Canva post¶
Canva explicitly defends MySQL as the correct choice for the first 2 years — "it served its purpose well … using the initial architecture also ensured that we could deliver our functionality to users in a reasonable timeframe". The issue wasn't MySQL; it was using OLTP MySQL for a scan-and-aggregate workload at exponential growth. (See concepts/oltp-vs-olap.)
Operational notes from real deployments¶
- Vertical scaling wall — doubling the RDS instance is the growth strategy; at TB-class sizes, zero-downtime upgrades dominate on-call budget.
- No built-in horizontal partitioning — sharding is an application-level exercise.
- Shared-instance blast radius — shared with other critical features, downtime in one hurts all; Canva did a "database split" to mitigate.
- Free-space burn rate is the useful forward metric. Canva reports ~500 GB / ~50% of free storage consumed in 6 months as the signal the strategy was ending.
Seen in¶
- sources/2024-04-29-canva-scaling-to-count-billions — MySQL RDS as the v1 store for Canva's usage-counting pipeline; hit vertical- scaling wall and was replaced by DynamoDB (raw events) + Snowflake (analytics).
- sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers
— MySQL (via Vitess) as one of the two engines
behind PlanetScale's Cloudflare-provisioned
managed-database offering. Accessed from
Workers through the Hyperdrive binding —
same binding shape as the Postgres path. Canonical instance of
patterns/partner-managed-service-as-native-binding on the MySQL
side. The article doesn't show MySQL code snippets (every example
is Postgres via
pg), but the integration is framed as co-equal to Postgres.