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 2026 on GCP c4-standard-48-lssd and AWS m8id.12xlarge / m8gd.12xlarge (Graviton4). See BENCHMARKING.md to run them yourself.

† pwrite + fdatasync into a preallocated file. Cloud SSDs and network disks have no write cache to flush (Azure Premium SSD flushes in ~30 μs), so a durable write costs a write.

* One TCP connection moves ~2 MiB per round trip, so 2 MiB / RTT: 20 MiB/s at 100 ms. Add connections to go faster.

Throughput is with enough requests in flight to max out a 48 vCPU VM (AWS m8, GCP C4) and its disks (EBS gp3, Hyperdisk Balanced at max provisioning; HDDs are 2 TB pd-standard). Regional disks copy every write to a second zone, so only their write latency differs. Blob Storage latency is p99 from the same region; Zonal is S3 Express One Zone and GCS Rapid. Region-to-region latencies: cloudping.

Approximate numbers that should be consistent between Cloud providers.

†† 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 at list price (one B200 per 25 vCPU):

Reading 1 TiB costs the VM time it takes at the row's throughput (48 vCPU + 192 GB is $1,700/month, $0.0006/s; the 1-thread row is one vCPU; the GPU row is a B200 at its 8 TB/s spec), plus the transfer and request fees above:

§ 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; 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, against the size of the text they index (documents of ~16 KiB for n-grams; at one line per document they're as big as the text):

• 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