Platform
Measured, not promised
These are figures from recorded benchmark runs, published with the conditions they were measured under. During an evaluation we run them again — at your volumes, with the decision traces open.
Results
The benchmark, in full
Every row is a measurement from a dated run in our engineering log. Nothing here is a projection.
Transactions loaded into one tenant
2,001,904
Across 300 supplier and customer entities
Value carried, exact to the cent
$501.86 billion
Fixed-point decimal — zero rounding error at that magnitude
Bulk ingest throughput
~20,000 rows/s
Batched load with row-level security forced throughout
Per-agreement accrual query
13 ms
One entity and transaction type at 2M rows, on the shipped indexes
The same query without its index
108 ms
A full scan of all 2M rows — the index makes the real path 8× faster
Whole-portfolio aggregation
~0.7 s
A sum across all 2M rows
Promoting 20,000 records with change capture
5 s
One statement per record; an earlier design measured 114 s for the same load
Method
How these were measured
A benchmark without its method is a marketing number. This is the method.
The machine
A single Apple Silicon workstation running PostgreSQL 16 as one node — no cluster, no read replicas, no caching tier in front. One machine is the honest baseline.
The data
Synthetic transactions generated by the platform’s own volume generator into one tenant’s transaction feed, across 300 supplier and customer entities — the same tables and indexes that every tenant gets.
The conditions
Row-level security forced throughout, exactly as in a live tenant. The accrual figure is the real calculation path — one agreement’s entity and transaction type — timed with and without its index to show what the index buys.
Why it stays fast
Architecture, not tuning
The numbers come from how the platform is built, which is why they hold as the feed grows rather than holding only on the day of the test.
Cost follows the rows that match
A real accrual is selective — specific agreements, entities and periods. On the shipped indexes its cost depends on the rows it matches, not on the size of the feed, which is why the per-agreement figure holds flat as volume grows.
Only what changed is summed again
Tiered and growth programmes keep their monthly sums in a measure store. A run re-sums only the months a change has touched since the last run; when nothing changed, it does not read the feed at all.
Calculation next to the data
The calculation engines run largely as functions inside PostgreSQL, so millions of rows are not shipped to an application server to be added up and sent back.
Reports read results, not raw rows
Financial dashboards read pre-computed snapshots refreshed on a schedule, rather than aggregating the whole transaction history every time they open.
Capture that stays linear
Change capture writes one small marker for each month a statement touches, and re-sending unchanged rows writes nothing — which is what turned 114 seconds into 5.
Isolation priced in
Every figure above was measured with row-level security forced on. Tenant isolation is not switched off to make a benchmark look better.
At your scale
Bring your own volume
Our numbers are a starting point. Yours are the ones that matter.
Tell us your annual transaction count, your number of agreements and how many trading partners send you data. We load synthetic data at that volume into a sandbox tenant, run the accrual, claim and reporting engines against it, and walk you through the timings with the decision traces open — so the figure you take into your business case is one you watched being produced.
For how the platform is built, isolated, traced and tested, see enterprise readiness.
Ask for a volume test at your scale.
Send us your transaction volumes and we will set up the run — your figures, measured in front of you, before anything is signed.