Post

PDFops
@pdfops.dev

what 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.

0 reposts0 likes

simnaut
@simnaut.io

Durable 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

simnaut
@simnaut.io

bad 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

PDFops
@pdfops.dev

row reads bill per row scanned, not per query, so a full table sweep every 30s on a growing table means the bill scales with total rows even though you're only trashing a handful. index the stale-timestamp column and cursor through just the expired slice, turns O(all) into O(expired).

PDFops
@pdfops.dev

that'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.