Platform
Measured performance.
Throughput per core for Govern services, with the hardware and method behind every figure.
How we measure
Figures you can check.
Telemetry
100,000 events a second, zero data loss, no Kafka.
Govern's own telemetry pipeline: intake writes each event to a write-ahead log on disk, ingest stores it in PostgreSQL, and older data is compacted into Parquet files on object storage or a local directory. No Kafka, separate analytics database or other streaming system is needed; Kafka is only an optional connector. Measured with every component and PostgreSQL sharing the same four cores, with events of about 550 bytes.
| Measure | Result |
|---|---|
| Intake, per core | About 250,000 events a second |
| Write-ahead log | About 500,000 records a second |
| Sustained, 60 seconds | 100,000 events a second, every event stored |
| Peak, 60 seconds | 150,000 events a second, every event stored |
| Soak, 5 minutes | 80,000 events a second, every event stored |
| From sending to stored, at 100,000 a second | 32 ms median, 809 ms at the 99th percentile |
| Compaction to Parquet | 277,000 rows a second, 25.7 times smaller |
| Query the archive: first 100 rows of an hour / a day | 2.0 ms / 15.8 ms |
| Query the archive: every row of a day (48,000) | 260 ms |
Zero data loss: under load we killed intake and ingest processes, cut every database connection, filled the disk and restarted components. In every run, every event produced was stored exactly once.
Data loss prevention applies when telemetry is read: every string in a query result passes your organisation's DLP redaction. The figures above measure intake and storage.
Policy decisions
An agent's action is checked in about 10 microseconds.
Agent policy is decided where the agent runs, from signed policy bundles, and every decision is written to a local write-ahead log; there is no network round trip. Measured on one core with a realistic organisation of 3 guardrails and 12 agent policies, CPU only.
| Measure | Result |
|---|---|
| Decision, including recording it | 10.2 µs; 97,800 a second per core |
| Latency, median / 99th percentile | 5.7 µs / 35 µs |
| Evaluation alone | 2.05 µs; 487,000 a second per core |
Audit log
Tens of thousands of audit entries a second, none lost.
Each organisation has its own hash-chained audit log. Three server replicas appended entries with every commit flushed to disk, and every acknowledged entry was checked to be stored exactly once. One run per row; the database shared the same four cores.
| Organisations, concurrent writers | Entries a second, 99th percentile |
|---|---|
| 1 organisation, 64 writers | 12,521; 11 ms |
| 1 organisation, 1,024 writers | 34,949; 114 ms |
| 50 organisations, 64 writers | 4,775; 39 ms |
| 50 organisations, 1,024 writers | 26,160; 111 ms |
| 500 organisations, 64 writers | 2,613; 80 ms |
| 500 organisations, 1,024 writers | 5,915; 488 ms |
In all nine runs, every acknowledged entry was stored exactly once. An entry can be read as soon as it is acknowledged: about 1 ms at the median.
Offline verification of a chain ran at 98,000 to 143,000 entries a second. Searching 100,000 entries for the newest 100, one action or the last hour took 1.2 to 1.6 ms at the median.
Sign-in tokens
Over 130,000 token checks a second per core.
The cost of issuing and checking access tokens, measured on one core, CPU only; the database work of a sign-in is not included. Password checks are slow on purpose, so single sign-on and passkeys are the fast path.
| Operation | Result |
|---|---|
| Check an access token | 7.6 µs; 132,000 a second per core |
| Issue an access and refresh token pair | 3.8 µs; 264,000 a second per core |
Sandboxes
A command in a sandbox answers in about 5 milliseconds.
Commands run in Firecracker microVMs and are measured end to end over the API, from request to result. Measured on one AWS m8i.2xlarge instance (8 vCPU) running the database, the API, the worker and 50 microVMs together.
| Command, concurrent callers | Median / 99th percentile |
|---|---|
| Empty command, 1 caller | 5.3 ms / 11.1 ms |
| Echo, 1 caller | 5.4 ms / 6.7 ms |
| Empty command, 10 callers | 22.2 ms / 42.7 ms |
| 1 MB of output, 1 caller | 42.9 ms / 90.4 ms |
| Empty command, through another server replica | 6.3 ms / 8.2 ms |
Output streams back as it is produced, and every result is stored exactly once, even when a connection drops. Files of up to 1 GiB move in pieces, checked end to end with SHA-256.
Directory sync
100,000 users synced in under two minutes.
Users created and updated through the SCIM service against PostgreSQL, 16 parallel streams as an identity provider pushes them, including each user's membership and log entry. The HTTP layer is not included.
| Users | Time |
|---|---|
| 10,000, created | 14 to 22 seconds |
| 100,000, created | 97 seconds |
| 100,000, updated in a full re-sync | 117 seconds |
DNS
Over 100,000 queries a second on one core.
The authoritative DNS server, pinned to one core, with the load generator on the other three. Signed answers cost about the same as unsigned ones, because the signature is cached with the answer.
| Query | Answers per second, one core |
|---|---|
| Simple A record | 114,926 |
| DNSSEC-signed A record | 107,502 |
| Name that does not exist (never cached) | 46,493 |
A record change was served by a replica within 2.6 ms at the median and 61.5 ms at the 99th percentile after the API answered, over 100 changes.
AI Gateway
Under a millisecond of overhead, with no database on the request path.
A dedicated AI Gateway, measured against a model stub that answers at once, so the figures are the gateway's own cost. Policy comes from signed bundles and every request is still checked, metered and recorded; the request path makes no database calls.
| Measure | Result |
|---|---|
| Requests per core, end to end over TCP | 3,380 to 3,460 a second |
| Requests per core, gateway work only | About 9,400 a second |
| Overhead, end to end at 2,000 to 3,000 requests a second | 0.06 to 0.08 ms median, 0.28 to 2.29 ms at the 99th percentile |
| Overhead, gateway work only | 0.03 ms median, 0.33 to 0.82 ms at the 99th percentile |
| Database statements on the request path | None |
| Memory per open stream | 107 to 118 KiB; 10,000 streams held on 2 cores |
Per core means per core of the gateway process's own CPU. Two in-process runs reached 2.06 ms and 4.82 ms at the 99th percentile while other load ran on the machine.
Streams
Over 270,000 records a second, on disk before they are acknowledged.
One Streams broker and its clients in one process, every write flushed to disk before it is acknowledged: 8 partitions, 1 KiB records, 64 concurrent producers.
| Scenario | Result |
|---|---|
| Synchronous produce, 64-record batches | 272,143 records a second (279 MB/s), 47 ms at the 99th percentile |
| Synchronous produce, 16-record batches | 92,786 records a second (95 MB/s), 45 ms at the 99th percentile |
| Batching producer, single sends | 166,447 records a second (170 MB/s), 14 ms at the 99th percentile |
| Three brokers, one copy | 110,789 records a second |
| Two copies, acknowledged by all | 61,547 records a second |
| Three copies, acknowledged by all | 35,380 records a second |
| Endpoint authorizer overhead per request | About 44 µs open; 99 to 125 µs with JWT |
| Sensitive-data screening of record payloads, block mode | 112 to 131 µs per 10-record request, against 42 to 46 µs without it |
The replicated runs put all three brokers on one disk and the same four cores, so every copy is a flush to the same disk; on separate machines the copies proceed in parallel.
In failure tests we killed and paused brokers under load over 20 iterations with three copies: all 412,159 acknowledged records were present at their offsets, none was stored twice, and every copy was byte-identical at the end.
What you run
Built from our own source.
Under load and failure
It keeps itself healthy, and tells you when it cannot.
Under NDA
Full reports, the code and the tools.
Under a non-disclosure agreement, your team can review the source code, receive our capacity and benchmark reports for the other services, and run our benchmark tools on your own hardware.
Talk to our team.
Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.