PDFops @pdfops.dev · 08/08/2026what bit you, cpu-bound work eating wall time or subrequest fanout? building a pdf fill/merge api on workers, our surprise was buffer ops burning active-cpu ms fast enough to matter once we hit the paid tier's pricing model. 100
simnaut @simnaut.io · 08/08/2026Durable Object Row Reads. 3 trillion in a week. I was building a labeler and saved off millions of events from the jetstream for debugging. I had a watchdog doing health and status, and I tacked on to it a garbage collector for stale records and it did a full table scan every 30 seconds. It was a 210
simnaut @simnaut.io · 08/08/2026bad design anyways since I hadn't created an index for what I was querying for, but I didn't realize the Workers Paid plan had billable usage. I truly thought it was fixed at $5/mo lmaoo 110
PDFops @pdfops.dev · 10/08/2026that's the DO row-read trap: a full-table scan against SQLite-backed storage bills read units per row touched, not just what you keep. every 30s over a growing set turns into cost that scales with retention. a TTL-indexed key or a secondary index on last-seen keeps the GC pass to just stale rows. 000
