At LinkedIn, my team runs a multi-primary MySQL system with roughly 20 billion rows across six tables and 15 TB of stored data. The tables aren't partitioned, and the system isn't sharded. Yet, our queries are still surprisingly fast. Most requests are small indexed lookups, and they repeatedly touch pages already in memory.

The system spans three regions, each with one primary and two local replicas.

One primary per region

Three regions, three primariesRegions A, B, and C each contain one primary and two local replicas. All three primaries exchange changes across regions. There are nine servers in total. Each cylinder is labeled with its role. Dashed arrows exchange changes between primaries; colored arrows feed local replicas.Region ARegion BRegion CPrimary APrimaryReplica in Region AReplicaReplica in Region AReplicaPrimary BPrimaryReplica in Region BReplicaReplica in Region BReplicaPrimary CPrimaryReplica in Region CReplicaReplica in Region CReplica
Each primary replicates across regions and to two replicas in its region.

Each instance has 32 cores, 256 GB of RAM, and 24 TB of disk. InnoDB's buffer pool caches data and index pages in memory, so frequently accessed pages can be read without fetching them from disk.

The hardware each MySQL instance runs on

CPU32 cores · 5% utilization

Each slot represents one core of capacity.

RAM256 GB · 39.1% buffer pool
100 GB buffer pool156 GB outside the pool

8 × 32 GB RAM modules

Disk24 TB · 62.5% stored data
15 TB stored data9 TB outside this dataset
Each MySQL instance runs on heavyweight hardware.

We see about 10,000 SELECTs per second, reported as the mean across all three regions. The average query time is 0.48 milliseconds. We mainly serve point lookups or lookups on indexed columns. Each query touches only a small number of rows and pages, so the database doesn't need to read through billions of rows to answer a request.

Reads and writes over 24 hours

reads10,000 / s mean
writes100 / s mean
Illustrative rates averaged across three regions. Reads average 10,000 per second and peak at 12,000. Writes average 100 per second and peak at 200. Both lines share a zero-based linear axis.
Illustrative daily pattern; rates are means across all three regions.

This workload mostly reads recent rows. Because our primary-key IDs increase over time, those rows tend to occupy nearby pages in InnoDB's clustered index, which stores rows in primary-key order. Secondary indexes follow their own key order. Repeated reads make those pages hot and useful to keep in the buffer pool; older history is rarely retrieved in this workload.

Reads favor recent rows

One B+ tree in the database5%25%70%ColdHotLower IDsOlder rowsHigher IDsNewer rows
In this example, most reads reach newer rows on the right.

Our buffer-pool size is 100 GB, with a hit rate of 98.7%. That rate measures page accesses served from memory rather than from disk. Frequently accessed pages tend to stay in memory; less frequently used pages can be evicted as space is needed. This depends on page access and cache pressure.

Most reads stay in memory

Frequent memory reads and occasional slow disk readsThe application sends concurrent page-read requests along eight parallel lanes to the database. Its 100 GB buffer pool serves 99 percent from memory. One percent miss and wait on the 15 TB disk, then load the page into the buffer pool before returning. Blue requests return quickly; orange requests take longer. This illustrative sample rounds the reported 98.7 percent hit rate.DATABASEAPPLICATIONBuffer pool100 GB · 99% hits~100 nsRAM accessDisk (SSD)15 TB · 1% misses~50 µsSSD accessRAMDiskcache miss

Illustrative page reads: 99% memory · 1% disk.

Conclusion

This workload combines small indexed lookups with repeated reads of recent rows. Those reads reuse pages in the buffer pool, which helps explain the high cache hit rate and fast average query time.