Last week I was evaluating some application performance characteristics with another architect. Our gut feeling told us that the numbers didn't make sense but we couldn't pinpoint why we had this feeling.
This reminded me of a recent Pragmatic Engineer podcast episode with Simon Eskildsen (co-founder of turbopuffer, ex-Shopify). He was talking about a habit that fixes exactly this: napkin math.
What is napkin math?
Napkin math means estimating how a system should perform, using a few known numbers and some arithmetic. No code, no prototype, no load test. You work from first principles: how fast can this machine read memory, how long does a round trip to S3 take, what does a gigabyte cost?
Simon turned this into a project. He collected the real numbers for latency, bandwidth and cost and kept them in a table on GitHub. Then he made flashcards for almost every cell, so he could recall them instantly during a design review.
That is a key point: he didn’t look the numbers up, he memorized them.
Use it as a benchmark sanity check
This is the use I recognize most. Simon described reviewing projects where a team picked Database A over Database B because of a benchmark. If the benchmark says a query takes 10 seconds and your napkin math says 10 milliseconds, one of you is wrong.
Either your mental model has a gap, or the benchmark measures the wrong thing. His example: the benchmark was running a distributed query across a hundred nodes, so of course the p99 looked terrible.
So the question becomes: do you trust the benchmark, or do you understand why it gives that number?
Mind the first-principle gap
Simon calls the difference between the estimate and reality the first-principle gap. His example is MySQL. His napkin math said roughly 1,000 fsyncs per second, so about 1,000 transactions per second. The measured result was around 5,300 inserts per second.
Faster than the theoretical limit is unusual. The explanation was group commit: MySQL batches multiple transactions into a single fsync. His model was incomplete, not the system. He later reused that idea for turbopuffer, grouping writes on top of object storage.
A gap like this means one of two things:
- An opportunity. The system is slower than it should be, so something can be improved.
- A flaw in your model. The system is doing something you don’t understand yet, so you learn something.
Both outcomes are useful. The only wrong outcome is not noticing the gap at all.
What I take from this
Three things I’ll apply with my teams:
- Estimate before you measure. Write down the expected number first. If you can’t, you probably don’t understand the system well enough yet.
- Learn a handful of numbers by heart. Memory vs. disk vs. network, and the cost of a GB in each. You don’t need 50. A dozen is enough to start.
- Treat a gap as a question, not a verdict. Don’t dismiss the benchmark and don’t dismiss your estimate. Find out why they differ.
One more point from the same interview that I liked: Simon said the simple solution someone built in a week or two often outlived the big, multi-team RFC solution. Napkin math pairs well with that. If the estimate says a simple design is good enough, you can stop there.
You don’t need a better benchmark. You need to know what answer to expect.