109 Records per Second on One 2-vCPU Node

On a deliberately-small AWS footprint - a single t3.medium node (2 vCPU / 4 GiB) running the API pods and the worker, Aurora Serverless v2 capped at 4 ACU - AGLedger 1.0.0 sustains:

• 109 records/sec for notarize-only records on a single pod. ~6,500/min, ~9.4M/day, zero errors - up from the 60/sec measured on the prior v0.22.18 sweep. The Notarize path for compliance recordkeeping.
• Zero forks across nearly one million records under restart chaos. 999,006 records notarized at ~108/sec sustained on two pods while a chaos loop force-killed a pod every ~45 seconds - 240 forced restarts in total. Every one of 9,992 export pages came back hash-chain-valid, and a 200-record sample re-verified 100% offline against out-of-band keys.
• 12 records/sec for full-lifecycle records (prior v0.22.18 sweep). Create + completion + verdict + Settlement Signal. About 1M/day on a single replica.
• ~20 jobs/sec federation drain(prior v0.22.18 sweep). Sustained outbound delivery to peer Servers under a 5-minute × 12-RPS soak.

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

The load number that matters most isn't throughput; it's integrity. The 1.0.0 run made that adversarial: ~1,000,000 notarizations attempted while a chaos loop force-deleted an API or worker pod every ~45 seconds. 993,663 committed; the only failures were 6,337 transient 503s (0.63%), every one during a forced restart - the kind a retrying client recovers - with zero corruption-class errors. The verifier then swept the whole vault: zero duplicate (recordId, chainPosition) pairs, zero payloadHash collisions, zero position anomalies across 999,118 vault entries; 9,992 of 9,992 export pages hash-chain-valid; counts reconciled with no lost writes; and a 200-record sample re-verified 100% offline with agledger verify --require-out-of-band-keys. One precision note: AGLedger's chain is per-record lineage (each notarization is a COSE_Sign1-signed root; delegation children extend a lineage), not one global linear chain - “zero forks” means those vault-wide invariants held, not that a single global chain survived.

The prior v0.22.18 sweep told the same story at lower intensity. Across its 5-minute × 8-parallel gated soak: 3,005 records, 9.99 sustained TPS, 0 client errors, 0 pod restarts, 0 federation outbound DLQ entries, and cross-Server chain math that closed signature for signature. Past that sweep's ceiling, the system degraded gracefully: at 100 RPS notarize the ALB returned 502s after the 10-second backend timeout, but the API pod stayed up and no records were 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.

These numbers are a floor, not a ceiling. The entire 1.0.0 run - both API pods plus the worker - fit on one t3.medium, with the autoscaling nodegroup sitting at zero the whole time, and the database capped at 4 ACU. The binding constraints were that 4-ACU cap and a 20-connection-per-pod pool, both trivially raised: Aurora Serverless v2 scales to 128 ACU - 32× what this run used - before read replicas, and node types go far beyond t3.medium.

API pods are stateless, so throughput scales with replica count until the database is the bottleneck. The shorthand: roughly N × 109 RPS notarize per N pods on adequately-sized nodes, with the prior sweep's 12 RPS gated and ~20 jobs/sec federation drain scaling on the same basis. HA and clustering are a vertical-scale motion (bigger DB, more API replicas behind the same Server), not a horizontal-shard motion.

1.0.0 refresh (2026-06-10): AWS EKS 1.36, Aurora PostgreSQL 17.9 Serverless v2 capped at 4 ACU, a single t3.medium node (2 vCPU / 4 GiB) running both API pods and the worker, each API pod requesting 0.25 vCPU / 256 MiB and capped at 1 vCPU / 512 MiB. AGLedger 1.0.0 GA, Docker Hub image digest sha256:821181d2…. Load run: two drivers at 500k notarizations each, with a chaos loop force-deleting an API or worker pod every ~45 seconds. The front-door rate limiter was disabled on the test instance so concurrency actually reached the append path; out of the box, the default customer rate limit is 200 requests per 60 seconds.

Prior v0.22.18 sweep: EKS 1.32, pods at 1 vCPU each, database at 0.5–4 ACU. Notarize sweep ramped 1 to 100 RPS over 30 seconds with the minimum valid notarize-only payload; lifecycle soak ran 5 minutes × 8 parallel clients at ~12 TPS, full create + activate + completion + verdict per record.

Not yet measured (gaps the next benchmark will close): gated-lifecycle and federation throughput on 1.0.0, latency percentiles on 1.0.0, multi-node horizontal scale (the chaos run's two pods shared one 2-vCPU node), and federation throughput across more than two organizations.

A single pod on hardware that costs cents per hour handles 109 records/sec notarize - and held its integrity invariants through 240 forced restarts on the way to nearly a million records. Most deployments won't touch the ceiling with a single replica. The ones who do scale with replica count and database ACU, with 32× of database headroom unused in this run.

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.