A number is only worth quoting if it is a rate
The ingestion pipeline I founded moves about 680 million rows a day. I wrote that sentence on this site, and it is true, and it tells you almost nothing. Here is what it took to replace it with numbers that do.
Totals hide shape
The 680 million is a mean over 31 days. The busiest day in that window did 1.33 billion; the quietest, 121 million. That spread is the first clue that the daily total is not the system's capacity — it's whatever the customers happened to send.
So I asked when the work arrives. Jobs are triggered hourly, but 73% of the day's ~8,900 jobs land in one six-hour window, when the small daily channels all fire. Rows are spread more evenly — the large jobs run at all hours — but the busiest single hour still moved 120 million rows, more than four times the hourly mean.
Utilisation is a mean of two different systems
My first pass computed fleet utilisation: job-hours divided by twelve workers times twenty-four hours. About 32%. Also true, also misleading — it averages a wave with a lull.
Sweeping every job's start and end and weighting by time gives the real shape. Through the six-hour window the twelve workers average 8.9 busy — 74% occupancy — with all twelve busy 15% of the time and the fleet idle 3% of it. Across the other eighteen hours they average 2.3 busy, and the fleet is completely idle 39% of the time. An hourly trigger fires, a burst of small jobs runs for a minute or two, and the machines go quiet again.
That's the honest statement: a twelve-wide fleet that works hard for six hours and mostly waits for eighteen. The 680 million is bounded by demand. The demonstrated envelope is twelve concurrent jobs and 120 million rows in an hour.
Stocks are not flows
The tagging engine I started in 2020 "holds 4.7 billion objects". For a while I nearly wrote "tags 4.7 billion objects", which would have implied a daily rate two orders of magnitude higher than the truth. The 4.7 billion is a stock — what is in the tables. The flow is in the database's write statistics: about 545 million updates and 37 million inserts a day, so the engine rewrites roughly 12% of what it holds every day. The rate is the impressive part, and it's the part I nearly left out by quoting the stock.
One channel is not the median
The pipeline's launch was announced internally as "20× faster". Going back to the record: that was one channel, one weekly run, five million rows, a day and a half to ninety minutes — and only after batching dereference. The largest daily workload went from 10–12 hours to 18 minutes. Across one customer's channels the median gain was nearer 5×, and one channel got slower. A colleague also pointed out at the time that the figures measured job time to the database, not when the customer could see the data. The 20× was real; quoting it alone was not.
The filter
Working through this left me with a rule I now apply to every number before it goes on a page:
- Never quote activity or size. Commit counts, ticket counts, lines of code, repositories, releases — they measure effort or cost, not outcome. A big number of any of them could describe a rich system or a bloated one, and the reader can't tell which.
- A number earns its place only as a rate, a ratio, or a volume against a constraint. "Five million rows" is nothing; "five million rows inside a daily window that the old job couldn't meet" is the claim.
- Find the shape before the total. Mean utilisation, mean throughput, mean latency — each is an average of the regimes you actually care about.
- Say which it is: stock or flow, one case or the median.
It removed about half the figures from my CV. The half that survived are the ones I'd defend in an interview, which is, in the end, the only test.
All figures from the production job, import-report and tagging-engine metadata databases, queried 29 August 2026 over the trailing 31 days. The worker count (twelve) is the maximum concurrency observed, which matches the deployed process count.