The goal of this project is to collect software, numbers, and techniques to quickly estimate the expected performance of systems from first-principles. For example, how quickly can you read 1 GB of memory? By composing these resources you should be able to answer interesting questions like: how much storage cost should you expect to pay for logging for an application with 100,000 RPS?

The best introduction to this skill is through my talk at SRECON.

The best way to practise napkin math in the grand domain of computers is to work on your own problems. The second-best is to subscribe to this newsletter where you'll get a problem every few weeks to practise on. It should only take you a few minutes to solve each one as your facility with these techniques improve.

The archive of problems to practise with are here. The solution will be in the following newsletter.

Below are numbers rounded for memorization, not faux precision. Last measured in October-November 2026, averaged over GCP C4 and AWS m8i (x86) and m8g (Graviton4), 48 vCPU each, and their local-SSD variants; network disks on Hyperdisk, EBS and pd-standard, HDDs on an AWS d3. Blob storage was measured in March 2026, and the GPU rows are NVIDIA's specs. See BENCHMARKING.md to run them yourself.

† pwrite + fdatasync into a preallocated file; one thread keeps 32 in flight with io_uring, and the latency is one at a time. Cloud SSDs and most network disks have no write cache to flush (pd-standard and Azure Premium SSD flush in 30-80 μs), so a durable write costs a write. HDDs flush theirs (~1 ms), which 32 in flight don't speed up.

‡ Only the largest shapes span two sockets. Reading the other socket's memory costs ~2x the latency, and all cores share the ~60 GiB/s link (Graviton4). Keep memory on the socket that reads it: Linux allocates on the node of the thread that first touches a page. Intel's largest VMs also split one socket into a NUMA node per die; another die costs 1.2x the latency and 0.7x one thread's bandwidth, but all cores lose only ~10%.

* One TCP connection moves ~3 MiB per round trip, so 3 MiB / RTT: 30 MiB/s at 100 ms. Throughput here is with 32 connections.

Every row is one latency and one throughput. The latency is one request at a time, each waiting for the last, at the size in parentheses: a natural unit, a cache line or a block, that's as fast as anything smaller. HDD random I/O uses 256 KiB, because the seek dwarfs the transfer. Throughput is the most we got at any size and any number of requests in flight (BENCHMARKING.md has the smallest size that reaches it), on a 48 vCPU VM and its disks: local NVMe SSDs striped together, EBS gp3 at 16k IOPS / 1000 MiB/s and Hyperdisk Balanced at 80k IOPS / 1600 MiB/s, 2 TB pd-standard for network HDDs. Large random requests are nearly sequential, so random and sequential throughput end up close. Regional disks copy every write to a second zone, which adds ~1 ms to every write.

Sort is the exception to max throughput: it runs at 1.3 GiB/s on 4 KiB and 300 MiB/s on 1 GiB, and 300 MiB/s is the number you need for anything big. CPU and memory rows marked 1 thread scale with cores until memory bandwidth runs out (on x86 a vCPU is half a core). x86 memory writes need non-temporal stores to get there; on one thread, a plain memset first reads every line it overwrites and gets half. Memory latency uses 2 MiB huge pages; 4 KiB pages add ~30%. Sequential reads take 5 ns because the prefetchers got there first, and the all-cores rows are with every core doing the same. A write only waits if something makes it: a plain store retires into the store buffer in ~1 ns, so the write latency is an atomic add, which has to own the line first. The +1 RTT rows are measured over loopback, so add the network's round trip; a proxy also adds one to its backend.

One TCP flow gets the VM's bandwidth on GCP but 5 Gbit/s (600 MiB/s) on AWS outside a placement group, and 3 MiB / RTT across regions (*). Blob Storage latency is p99 from the same region; Zonal is S3 Express One Zone and GCS Rapid. Conditional writes are compare-and-swap on one object, one at a time; regional GCS also allows only ~1 write per second to the same object. Region-to-region latencies: cloudping.

Approximate numbers that should be consistent between Cloud providers.

‖ Provisioned on SSD network disks, above the first 3,000 IOPS and ~125 MiB/s, which are free. Network HDDs get theirs with their size.

CDN Egress for 1 year is CloudFront's Security Savings Bundle.

†† This refers to network leaving your cloud provider, e.g. sending data to S3 from GCP or egress network for sending HTML from AWS to a client.

¶ CDNs also charge ~$1 per 1M requests, cache hits included.

♣ Datadog charges $0.1/GB ingested plus ~$1.5 per 1M indexed events for 7d retention.

Furthermore, for blob storage (S3/GCS/R2/...), you're charged per read/write operation (fewer, large files is cheaper):

Zonal buckets also charge $0.003 per GB written and $0.0006 per GB read.

Instance shapes are the same few ratios on every cloud, here per vCPU averaged over AWS and GCP (HDD and B200s are AWS's; GCP has no local HDD) at list price in their cheapest US region: on-demand, a 1-year Compute Savings Plan or committed use discount with no upfront, and spot, the 75th percentile across every region of both clouds. One B200 comes with 25 vCPU. Most cost a vCPU plus its memory and disks at the unit prices above; the largest memory shapes and B200s cost more. The HDD shape's drives are 14 TB, so at ~100 random reads/s each it does ~7 reads/s per TB:

Reading 1 TiB costs the compute's time at the row's throughput (1 TiB / throughput x the shape's $ / month / 2.6M seconds, from the tables above), plus the transfer and request fees above. The compute is 48 vCPU of General for network, 48 vCPU of General, SSD for local SSDs, one vCPU of General for the 1-thread memory row, 2 vCPU of HDD for one 14 TB drive, and a B200 for the GPU row. Local disks pay their rent in those shapes. Network disks use just enough General to reach them, at ~40 MB/s per vCPU, plus the rent while it reads: 1 TiB of SSD with 16k IOPS and 1000 MiB/s, or 2 TB of HDD. Blob rent while reading rounds to nothing:

§ Zonal GETs cost 4x less, but every byte read costs $0.6/TiB, so zonal is cheaper below ~500 KiB per request and regional above.

Measured with cpu_compress; each range spans lz4 to zstd -19. Note that compression speeds (but generally not ratios) vary by orders of magnitude depending on the algorithm and the level of compression (which trades speed for compression).

I typically ballpark that another x in compression ratio decreases performance by 10x. E.g. on the Silesia corpus, lz4 gets 2x at ~500 MiB/s, zstd -9 3.5x at ~50 MiB/s and zstd -19 4x at ~3 MiB/s.

Structured data, against its in-memory size (8 bytes per float64, the type's width per integer, the bytes plus a 4-byte offset per string), measured on real datasets with compression_ratio and compression_ratio_columns:

ALP gets the same ratio as zstd on floats and decodes at ~10 GiB/s on one core. Floats that use the full mantissa (coordinates, model weights) barely compress at all. Bitpacked integers take log2 of each 1024-value range in bits and decode at ~15 GiB/s into a whole column, ~50 GiB/s a block at a time into cache; sorted or low-cardinality columns need RLE or a dictionary first. FSST decodes at ~2 GiB/s and keeps every string decodable on its own, where zstd over a whole column gets 3-10x. Dictionary and RLE columns also pay for the dictionary itself (each distinct value once); the smaller of the two rules predicts Parquet's dictionary + RLE size of whole tables within 10%.

Search indexes, as a fraction of the text they index, with Tantivy's posting lists (n-grams per source file for code, per ~16 KiB otherwise). Bloom filters are per 1 MiB block; a query still decompresses and scans every block that matches:

• Don't overcomplicate. If you are basing your calculation on more than 6 assumptions, you're likely making it harder than it should be.
• Keep the units. They're good checksumming. Wolframalpha has terrific support if you need a hand in converting e.g. KiB to TiB.
• Calculate with exponents. A lot of back-of-the-envelope calculations are done with just coefficients and exponents, e.g. c * 10^e. Your goal is to get within an order of magnitude right--that's just e. c matters a lot less. Only worrying about single-digit coefficients and exponents makes it much easier on a napkin (not to speak of all the zeros you avoid writing).
• Perform Fermi decomposition. Write down things you can guess at until you can start to hint at an answer. When you want to know the cost of storage for logging, you're going to want to know how big a log line is, how many of those you have per second, what that costs, and so on.

• Systems Performance (book). Fantastic book about analyzing system performance, finding bottlenecks, and understanding operating systems.
• Files are hard