A telco billing run isn't slow because writing rows is slow. It's slow because of the decision behind every row — which tariff applies, under which conditions, at what rate, for this account, on this date.

Multiply that by tens of thousands of transactions and naïve code grinds to a halt — usually because it asks the database the same questions over and over.

31,389
transactions · one run
37
minutes, start to finish
~1,370
peak / minute

On our platform, Digent.Billing, a recent production run processed 31,389 billable transactions in 37 minutes. Our fastest clean run held about 1,370 transactions a minute. These aren't estimates — they come straight from the system's own run log, with start and end timestamps for every batch.

Verified production runs
Transactions per minute · source: scheduler run log
21,905 / 16m
1,368
18,064 / 14m
1,267
25,455 / 20m
1,255
24,006 / 19m
1,241
25,448 / 29m
885
31,389 / 37m
839

Three decisions get us there

01Load the reference data once

Tariffs, conditions, configuration, account data — fetched a handful of times at the start of the run, then matched in memory. Not re-queried for every transaction. This single choice is the difference between 37 minutes and several hours.

02Run in parallel, but deliberately

Several transactions evaluate concurrently, each in its own isolated database scope. Enough to keep the cores and the connection pool busy; bounded enough never to swamp them or trip over each other.

03Write in batches, atomically

Line items go in grouped per invoice, billed flags flip in a single set-based update, and every invoice is committed all-or-nothing. That commit costs a little time at the end — and it's the best money we spend, because a half-written invoice is worse than a slow one.

Here's the detail I like most: this runs on a modest cloud VM with 8 GB of RAM — PostgreSQL on Linux, the application on Windows Server. No exotic hardware, no cluster. Just careful engineering: do the expensive thinking once, in memory, and let the database do what it's good at.

Fast is easy to fake in a demo. Fast and provably correct, on real production data, on ordinary hardware — that's the actual job.

And every one of those 31,000 transactions stays traceable — the system records why each was billed or skipped, and a database-level guard makes it impossible for a transaction to leak across two invoices. Because the tariff logic is configuration, not code, the same engine runs for any client without us rewriting it.