Why MySQL Outperforms NoSQL for High‑Throughput Key‑Value Storage

Background

Although MySQL is a mature relational database, the article argues that for key‑value storage scenarios it can deliver better performance, ease of use, and stability than many NoSQL engines.

Why developers gravitate toward NoSQL

Many developers choose NoSQL based on hype or the assumption that relational databases are inherently slower, focusing on operational cost, maturity, and lock‑free designs. The article cites Jepsen tests as a reference for comparing limitations.

Wix case study: routing and traditional normalized model

When a user requests a Wix site, the system must resolve the URL via a routing table. Using a conventional normalized schema requires multi‑table transactions, table‑level locks, and several joins (four in the example), which reduces throughput and increases latency.

Performance bottlenecks of the normalized approach

Table locks limit concurrent access.

Multiple SQL queries or joins increase latency.

Serial keys introduce additional write contention.

Wix's optimized MySQL model and results

By treating MySQL as a NoSQL engine, Wix achieved:

Active‑active deployment across three data centers.

Throughput around 200,000 RPM.

Routing table with ~100 million rows (≈10 GB).

Site table with ~100 million rows (≈200 GB).

Average read latency 1.0‑1.5 ms (0.2‑0.3 ms within a single data center).

These figures demonstrate that MySQL can meet or exceed typical NoSQL latency expectations.

Optimized schema design

The new model stores fields that are not used for queries inside a single blob (e.g., site_data) and avoids traditional serial keys, using a VARCHAR(50) GUID generated by the client as the primary key. Foreign keys are omitted, and only indexed fields are kept in separate columns.

High‑throughput query example

The query first uses a unique index on the routing table to fetch a single row, then uses the retrieved primary key to read the corresponding site row. The nested query ensures each table is accessed only once.

Results show sub‑millisecond average latency, consistent consistency under high traffic, and semi‑transactional inserts (the full site address is written in a single statement).

Practical recommendations

Avoid transactions; control atomicity at the application level.

Do not use serial keys; they introduce locks.

Generate client‑side GUIDs for primary keys.

Do not normalize; keep all non‑indexed data in a blob / JSON / XML column.

Do not define foreign keys.

Design the schema so each query reads only one row.

Avoid ALTER on live tables; use real‑time migration instead.

Read using primary keys or indexed columns only; avoid joins and aggregation functions.

Run complex analytics on replicas, not on the master.

Conclusion

Using MySQL as a NoSQL engine is feasible and can deliver low latency, high throughput, and strong consistency for key‑value workloads, making it a compelling alternative to dedicated NoSQL solutions.