Concurrency vs. Throughput: why more parallelism can make databases slower

A production MySQL outage illustrated how excessive database concurrency can reduce throughput: a batch transaction held locks for fifteen minutes, while thousands of retried snapshot reads accumulated, forcing InnoDB to traverse expanding row-version histories, exhaust buffer-pool capacity, and spread failures beyond the affected rows. The problem was amplified after migration from Cloud SQL’s thread-pool queuing model to Vitess configuration that allowed up to 10,000 open transactions and returned pool-full errors, encouraging application retries rather than applying backpressure. Drawing on Little’s Law and the Universal Scalability Law, the account explains that concurrency improves throughput only until contention and coordination costs make requests mutually slower, potentially causing “retrograde scaling.” Reducing the Vitess transaction-pool limit to roughly 1,000 and queueing requests with bounded waits restored controlled backpressure, allowing later traffic bursts to sustain about 60,000 queries per second with no disruption and fewer than 200 statements executing in MySQL. The approach is particularly relevant to workloads with hot rows, long transactions, locking, and shared state, and similar transaction-pooling strategies can also help PostgreSQL systems.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.