A 14-year AWS engineer shares hard-won lessons from building control planes for EC2 and Aurora DSQL. The post explains what control planes are, how EC2's MySQL-backed control plane evolved through read replicas, sharding, and availability zones to handle massive scale, and how those painful lessons directly shaped DSQL's architecture. Key themes include static stability, the human cost of immature automation, the circular dependency of self-hosting, and why DSQL (built on Firecracker micro-VMs with automatic scaling and strong consistency) removes many of the scaling cliffs EC2 teams had to climb manually. The author is candid about DSQL's current gaps, such as missing foreign key constraints and latency trade-offs versus single-node Postgres.

19m read timeFrom allthingsdistributed.com
Post cover image
Table of contents
On building scalable control planesWhat is a control plane anyway?Living inside the control planeSearching for Database Xanadu“Self-hosting”Taking off the rose-tinted glassesLooking around corners
248 Impressions