What the Vericto proxy adds: a latency and CPU benchmark

Summary

BENCH-2026-11 is the official benchmark of vericto-proxy: two dedicated EC2 instances, the direct path to the database measured in the same run, three interleaved repetitions and a repeat on another day on fresh hosts. The figures, with their conditions:

• PostgreSQL (pgbench select-only, extended protocol, one statement per request): the proxy added 0.12 ms at the median from 603 to 3,016 statements/s, and 0.14 ms at 4,223/s. The direct path took 0.29 to 0.31 ms at the median.
• MySQL (sysbench oltp_read_only, 16 statements and about 40 KB per transaction): 1.6 ms per transaction, about 0.1 ms per statement, from 36 to 250 transactions/s.
• The tail depends on load: the added p99 on PostgreSQL was 0.19 ms at 10% of the task's capacity, 1.34 ms at 30% and 2.71 ms at 50%. At 0.5 vCPU that tail is mostly the wait for the CPU quota, not the evaluation: size the task to run at about 50% of its CPU.
• Cost and scale: about 0.1 vCPU per 1,000 statements/s (0.105 on PostgreSQL, 0.097 on MySQL). Two 0.5 vCPU tasks sustained 9,049 statements/s against 4,826/s for one, about 1.9 times, with the load split evenly.
• Stable: on the second day, on fresh hosts, the added median moved by at most 0.03 ms up to 70% of capacity.

These are small statements: a larger statement adds more, and the statement-size sweep has not run on EC2 yet (see Limitations). It is a measurement under these conditions, not a guarantee.

What we measured, and why

A SQL firewall sits in the path of every query: everything your application sends crosses it before it reaches the database. Its cost is not only evaluating the rules, which takes microseconds in process; it is the whole extra hop: two TLS sessions, reading the protocol, evaluating the rules and sending telemetry. That is what we measured: the latency the proxy adds over going straight to the database, at fixed rates, and the CPU it uses to do it.

Three numbers often get mixed up: rule evaluation (microseconds, in process), added latency (what your application notices) and throughput (how much one task carries before its latency degrades). This page publishes the last two, each with its conditions, and shows the tail (p99), not just the median.

Setup

Method

• Open loop at fixed rates. Request i is due at start + i/rate, and latency is measured from that intended time, not from when it left: a stall counts against every request due during it (no coordinated omission). pgbench -R uses a Poisson schedule, and its lag is added to the latency. HdrHistogram histograms with 3 significant digits, one interval every 10 s.
• Cells. 60 s of warm-up discarded and 300 s measured, at 10, 30, 50, 70, 80, 90 and 100% of S, with the same absolute rates for every target. S is the closed-loop maximum of Vericto enforce at 0.5 vCPU with TLS: 6,033 statements/s on PostgreSQL and 357 transactions/s (5,706 statements/s) on MySQL.
• Repetitions. 3 per rate, interleaved: every target runs at a rate before the next rate, in an order from a seeded balanced Latin square. The headline curves were repeated on a second day on freshly created hosts, at the same rates, with 1 repetition.
• Added latency. In each repetition, Vericto minus direct at the same rate in the same repetition, percentile by percentile; across repetitions, the mean with a Student t 95% interval. An interval that contains zero is published as "not distinguishable from the direct path", never as zero.
• Validity, with no outlier removal. A repetition is invalid only for a reason registered before the run (errors above 0.1%, load-generator CPU above 70%, steal time above 1%, a cell that is not steady); it is kept in the raw data and rerun once. A cell whose achieved rate falls below 99% of the offered rate is saturated: it ends the curve and is never quoted as latency.
• Traffic caps. Every interface is counted every second; a cell aborts above 400 Mbps per component or 800 Mbps in total for 3 consecutive seconds. No published open-loop cell was aborted; on MySQL, the closed-loop steps of the faster baselines did hit the cap.
• Generator check. Once a minute, during an open-loop cell, the database is paused for one second: an honest generator must see it in about 1% of requests. It saw it in 0.97% and 0.95% (0.83% expected).
• CPU. The proxy container's CPU (cgroup) every second, and a linear fit against the statements/s it carried, over the open-loop cells below 80% of S.

Results

Day 1, mean of 3 repetitions with its 95% interval. Published latency goes up to 70% of S: on day 2, on another host, the PostgreSQL 80% cell was no longer steady.

PostgreSQL: added latency by rate

The median hardly moves with load (0.12 to 0.14 ms). The p99 does: from 0.19 ms at 10% of S to 2.71 ms at 50% and 3.47 ms at 70%. HAProxy in TCP mode, with the same core and quota, added 0.03 to 0.04 ms at p50 and 0.04 to 0.07 ms at p99: the hop alone is cheap. HAProxy relays the TLS session untouched; the proxy terminates and reopens TLS on both legs, reads the protocol and evaluates the rules. How that cost splits between the parts is in the follow-up batch.

MySQL: added latency per transaction

Per 16-statement transaction, the proxy added 1.57 to 1.73 ms at the median, about 0.1 ms per statement, flat from 10 to 70% of S. The p99 was 1.96 ms at 10% and 3.6 to 4.3 ms from 30 to 70%. HAProxy added 0.44 to 0.51 ms per transaction: each transaction returns about 40 KB, which any intermediary has to relay.

CPU against throughput

The cost is linear: about 0.1 vCPU per 1,000 statements/s on both engines, starting near zero. At the Fargate ARM64 list price (USD 0.03238 per vCPU-hour) and a 70% utilisation target, that is about USD 3.6 (PostgreSQL) and 3.3 (MySQL) per month per 1,000 statements/s.

One task or two

On staging, two tasks had saturated below the one-task curve; on EC2 that does not reproduce. Two tasks sustained 9,049 statements/s against 4,826/s for one (the 80% cell of the day-1 curve), about 1.9 times, with the load split evenly (0.44 and 0.48 vCPU). At the same rate, two tasks cut the added p99 from 1.44 to 0.25 ms (1,810/s), because each works at half the pressure on its quota. With one task, the same host saturated at 5,429/s.

Day 1 against day 2

Up to 70% of S, the added median moved by at most 0.012 ms on PostgreSQL and 0.030 ms on MySQL between days and hosts; the p99 by at most 0.64 ms (PostgreSQL at 70%, inside day 1's interval) and 0.18 ms on MySQL. On the day-2 host the PostgreSQL 80% cell was not steady (the knee came earlier), which is why the published figures stop at 70% of S.

How to read it, and sizing

• Budget about 0.1 vCPU per 1,000 statements/s. In the test, 1,810 statements/s used 0.20 vCPU, 40% of the quota of a 0.5 vCPU task.
• Scale out at about 50% CPU. The p99 grows with the load on the quota: 0.19 ms with the task at 14% of its CPU (603/s), 1.34 ms at 40% (1,810/s), 2.71 ms at 65% (3,016/s) and 3.47 ms at 90% (4,223/s). Adding a task spreads the pressure: with two tasks, the p99 at 1,810/s was 0.25 ms.
• Why the tail rises under a small quota. 0.5 vCPU is a CFS quota: the task may use half of every scheduling period. When a burst uses up the quota early, every statement that arrives afterwards waits for the next period, however fast the proxy is. The median does not see it; the p99 does, more often the busier the task. The 1 vCPU curve, which separates those waits from the proxy's own cost, is in the follow-up batch.
• Deploy the proxy next to the database. Here the proxy-to-database leg is on the same host; in a VPC, every network hop adds its own round trip. Put the proxy in the same availability zone as the database.
• Measure it with your own traffic. Every audit-trail event stores the latency of its evaluation (latency_ms), so you can compare these figures with yours.

Limitations

• Not staging. The figures come from dedicated EC2. The staging sessions (Fargate behind an NLB and Aurora, inside one VPC) are context and are not the headline. One instance family only (Graviton3): the Intel cross-check was dropped for budget.
• Small statements only. A key lookup on PostgreSQL and a 16-statement read transaction on MySQL. What is added grows with statement size; the size sweep is in the follow-up batch, and until then the reference is the staging curve below.
• Not run yet (follow-up batch): the statement-size sweep, large results and masked columns, observe and offline modes in open loop, 1 vCPU, the PgBouncer and ProxySQL baselines, TLS off, tpcb-like and the other protocol modes, the ORM-style mix, blocked statements and connection setup.
• MySQL at high rates is limited by the traffic cap, not by the proxy: at about 40 KB per transaction, the closed-loop maxima of the faster baselines pass 400 Mbps, and those steps were aborted on purpose.
• The environment is kinder than yours on two points: the leg to the database is local, and the stand-in control plane answers instantly (the backend's ingest cost is not measured here). Built-in rules only: no custom rules, allowlists or masking.
• Day 2 has 1 repetition per cell: it tests stability, it does not narrow the intervals. The day-1 cells shared the load generator with one-second bursts from the harness's progress sync (fixed for later runs; day 2 matches day 1). Each cell lasts 5 minutes: memory growth over hours is not covered.

Reproduce it

The harness is vericto-bench (Apache-2.0): the Terraform for the two hosts, the runner, the suites, the analysis and the report that produced every table on this page. Anyone can run it in their own AWS account, without Vericto's backend; the whole campaign cost about USD 18 at list prices.

Code: github.com/vericto/vericto-bench. Results of this campaign (manifests, cells, reports, charts and SHA-256 checksums): results/bench-2026-11.

Raw data

The per-interval histograms, the pgbench per-transaction logs, the CPU and traffic counters and the proxy logs: 3.9 GB, kept with their SHA-256 checksums. They are available on request through contact until they are published with the repository.

Earlier staging measurements (context)

Before this run, on staging on October 16, 2026 (vericto-proxy 4.12.0 on a 0.25 vCPU ARM64 Fargate task, Aurora Serverless v2, TLS, enforce mode, an ORM-style mix), we measured what BENCH-2026-11 does not cover yet. They are context, not headline figures:

• Statement size: on PostgreSQL, a 10-row INSERT added 0.58 ms at p50; 100 rows, 1.05 ms, already above a millisecond; 500 rows, 3.07 ms; 1,000 rows, 5.54 ms.
• Rule evaluation alone, no network: p99 of 100 µs or less for the OLTP statements (vericto-engine 3.9.0).
• Telemetry: 0 of the 1,222,254 events sent to the control plane during the session were lost.

Keep reading

• Rules reference: what the proxy evaluates
• Integration guide: deploying the proxy
• Architecture: microservices and Kubernetes