← Blog2026-05-19Engineering

60 Records per Second on a Single Replica

By Michael Cooper · Founder

Note: Numbers in this post were measured on AGLedger v0.22.18. The current API baseline is v0.23.0 (2026-05-19). Methodology and direction hold; specific magnitudes may differ on the current version.

v0.23.0 stamp on the smallest AWS footprint we could deploy. Notarize-only, gated lifecycle, federation drain, integrity invariants under load. The numbers, the methodology, and what they imply at scale.

Note: the throughput numbers below were measured on v0.22.18. The v0.23.0 release is an envelope cut-over (COSE_Sign1 over in-toto v1 Statement payloads, replacing JCS + detached Ed25519) — a wire-format change, not a hot-path performance change. We do not expect the numbers below to shift materially; the next benchmark sweep will confirm.

The numbers

On a deliberately-small AWS footprint (1 vCPU API pod, 1 vCPU worker pod, Aurora Serverless v2 sized 0.5–4 ACU, single replica each), AGLedger sustains (measured on v0.22.18; v0.23.0 envelope cut-over is wire-format only and is not expected to shift these numbers materially):

60 records/sec for notarize-only records. 3,600/min, 5.2M/day. The Notarize path for compliance recordkeeping. p50 224ms, p99 1.05s, zero errors.
12 records/sec for full-lifecycle records. Create + receipt + verdict + Settlement Signal. About 1M/day on a single replica.
~20 jobs/sec federation drain. Sustained outbound delivery to peer Servers under a 5-minute × 12-RPS soak.
100% chain integrity under sustained load and bursts. Zero record loss under back-pressure. Past the ceiling (we tested 100 RPS notarize, ~1.7×), the load balancer returns 502s but the pod stays up: graceful saturation, not crash.

Two flows, two ceilings

AGLedger has two flows, and they have different cost profiles:

Notarize (1 call): 60 RPS sustained

POST /v1/records → record terminalizes at RECORDED. One DB transaction: insert the record, append the chain entry, sign, commit. p50 224ms, p99 1.05s. CPU-bound on the API pod; Ed25519 signing dominates per-request cost.

Gated (4 calls): 12 RPS sustained

Create → Activate → Submit Completion → Render Verdict. Each call writes its own chain entry. The completion phase triggers async tolerance verification on the worker; the verdict phase emits the Settlement Signal webhook. Rate ceiling is set by the worker pod and the DB-write pipeline, not by the API.

Customers usually run both: the Notarize path covers routine agent activity, and the Verify path covers cross-org commercial work where a verdict and Settlement Signal need to fire. The two ceilings combine additively at the worker layer.

Chain integrity under load

The load number that matters most isn't throughput; it's integrity. Across the 5-minute × 8-parallel soak: 3,005 records, 9.99 sustained TPS, 0 client errors, 0 pod restarts, 0 federation outbound DLQ entries. Aurora stayed within the lower half of the configured 0.5–4 ACU window for the full soak; the database was not the bottleneck at this load. Cross-Server chain math closed cleanly: originator and receiver chains matched signature for signature across the soak.

Past the ceiling, the system degrades gracefully. At 100 RPS notarize, the ALB returns 502s after the 10-second backend timeout, but the API pod stays up and no records are lost. The audit chain stays consistent because writes are transactional: either the chain entry commits with the record or neither does. Distributed-systems work like Jepsen has shown how often invariants like “no record loss under back-pressure” fail to hold once you actually measure them; we hold this one open as a soak invariant the testbed re-checks on every release rather than a once-and-done claim.

Scaling up

The single-replica numbers above are the baseline, not the ceiling. API pods are stateless, so throughput scales linearly with replica count. Workers are pg-boss work-stealing, so throughput scales linearly until the database is the bottleneck. Aurora ACU max is the soft ceiling on any single-cluster deployment.

The shorthand: N replicas + 4N ACU behind one Server sustains roughly N × 60 RPS notarize, with federation-outbound drain holding at ~20 jobs/sec per Server. Three replicas + 12 ACU on the same cluster sustains roughly 180 RPS notarize and 36 RPS gated — past the accountability profile of any deployment we have benchmarked against. HA and clustering are a vertical-scale motion (bigger DB, more API replicas behind the same Server), not a horizontal-shard motion.

Methodology

Test infrastructure: AWS EKS 1.32 in us-west-2, ALB Ingress with ACM wildcard cert, Aurora Serverless v2 PG 17. AGLedger image agledger/agledger:0.22.18 (the pinned Docker Hub digest at this tag is in the public install repo). Pods sized at 1 vCPU each; database at 0.5–4 ACU. The v0.23.0 release ships the envelope cut-over to COSE_Sign1; a fresh sweep on that image is on the next benchmark.

Notarize sweep: 30-second ramp from 1 to 100 RPS, payload fixed at the minimum valid notarize-only record. Lifecycle soak: 5 minutes × 8 parallel clients × ~12 TPS, full create + activate + completion + verdict per record. The full methodology and harness live in our internal testbed; key parameters are summarized above so the run is reproducible against the same v0.22.18 deployment.

Not yet measured (gaps the next benchmark will close): multi-replica horizontal scale, lifecycle p99 under sustained load, true burst-capacity numbers, federation throughput across more than two organizations.

What this means in practice

The smallest configuration AWS sells handles 60 records/sec notarize and 12 records/sec full gated lifecycle, with full chain integrity. Most customers won't touch the ceiling with a single replica. The ones who do scale linearly with replica count and database ACU.

The load profile of an LLM agent fleet is small relative to modern databases. AGLedger is not going to be the bottleneck that forces a second instance or a more expensive database tier. The integration cost question is about your agents and your operational practices, not about whether the recordkeeper keeps up.