How to Assess Your Cloud Native Workloads for Migration to a Distributed SQL Database
summary
Benchmarks compare YugabyteDB against MySQL and others on a TPC-C–like workload (150k customers, 500k inventory, 100k items, 50 terminals with 10 parallel workers), showing initial throughput lag but improving to exceed MySQL after three tunings: smart client driver, periodic compaction, and explicit hash sharding for primary keys. Multi-AZ or multi-region HA halves to ~1.5x lower throughput under peak load. Conclusion: choose distributed SQL when you need true scale-out writes and cloud-level HA; skip it for single-shard write patterns.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:27Cloud native DB requirements
- 3:37Workload patterns
- 6:51High availability needs
- 8:58Distributed SQL characteristics
- 11:11Benchmarking distributed SQL
- 15:53Performance tuning tips
- 21:59Scalability comparison
- 23:27Key takeaways
- 24:52Summary
related talks
30mBuilding Cloud Native Applications on Distributed SQL Platform
26mA Winning Multi Cloud Data Strategy
29mEnterprise Scale: How a Distributed Architecture Can Deliver Scale and Resilience
08mScalable GraphQL Applications Powered by Cloud-ready Distributed SQL Database
30mBuilding Scalable Spring Applications with YugabyteDB
30mTechnical Comparison of YugabyteDB with Oracle and PostgreSQL
47mAnatomy of a Distributed SQL Database - YugabyteDB
02h 27mDistributed SQL Tuning and Optimization in YugabyteDB