Platform

Measured performance.

Throughput per core for Govern services, with the hardware and method behind every figure.

How we measure

Figures you can check.

Measured, not estimatedEvery figure here was measured. We do not extrapolate from one service to another; components without a published result are not listed.

A floor, not a ceilingUnless a section says otherwise, runs were on one shared 4-vCPU virtual machine (Intel Xeon, 2.1 GHz) with other load tests running at the same time, and with the load generator, the database and every component on the same cores. Dedicated hardware does better.

Per coreWhere we can, we give throughput per CPU core, so you can size your own deployment from your hardware.

Check it yourselfUnder a non-disclosure agreement, you receive the full reports and our benchmark tools, and can run them on your own hardware.

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.

Our own codeGovern's services, including the vault, key management, DNS, streams, telemetry, sandboxes and cloud workspaces, are written by Neural Inverse. They are not copies or forks of open-source projects, and not resold or wrapped third-party services.

One databaseThe only other service they need is PostgreSQL. Long-term archives go to S3-compatible object storage or a local directory. Sandboxes and workspaces run in Firecracker microVMs, the open-source virtual machine runtime, on your compute hosts.

No extra licencesYou need no separate licence for any of them. PostgreSQL and Firecracker are open source and need no paid licence. Our code uses open-source libraries, not open-source services.

No outside callsThe services make no calls to external services at runtime, so they run the same on a closed network.

Under load and failure

It keeps itself healthy, and tells you when it cannot.

Sheds load before it failsAn adaptive concurrency limit with request classes: health probes are never shed, sign-in keeps headroom, and exports and bulk jobs give way first. One organisation can hold only a share of capacity.

Repairs itself, within limitsRemediation playbooks recycle database connections, restart stalled jobs, release memory or shed batch traffic, then check that the repair worked. Disruptive actions such as draining a node wait for an operator's approval, and a kill switch stops them all.

Watches its own healthBaselines learnt per hour of the week, burn-rate rules on availability, and canaries of its own sign-in endpoints. Detection and alerting keep running from memory while the database is down.

Across every partThe same self-healing runs in the data plane, the compliance plane, the provisioner and the sandbox daemons.

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.

Ask for the reports

Deployment options

Talk to our team.

Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.

Request access Contact us