SQL through the gateway: first latency
First pgbench runs through the gateway: a one-row insert takes about 1 ms, but a primary-key lookup costs as much as a GROUP BY and nothing scales with clients.
Run details
| Date | |
|---|---|
| Commit | 2c4c91a |
| Host | sttiz, shared production VPS under the uf-remote caps: 3 CPUs, 6 GB. |
| Tool | UF_BENCH=1 bash scripts/p3a-e2e-host.sh under uf-remote. Path: pgbench 16, simple protocol, loopback TCP → ufgw → Unix socket → ufd --jwks. Data: the end-to-end tables (tenant A: 10 000 orders; tenant B: 100), 10 s per run. |
| Raw results | No separate raw file; the figures are those printed by pgbench in the run and recorded in the report. |
| Report | docs/bench/2026-10-23-p3a-sql.md |
Indicative only. Measured on a shared development host with other services running, one node, data that fits in memory. These figures show direction, not performance to expect. The claims policy requires a dedicated host before any target is published.
The tables, as written
Transcribed from the report without rounding. Bracketed values are the previous measurement where the report gives one.
pgbench, simple protocol, 10 s per run
| Statement | Clients | Latency avg (ms) | Statements/s | Failed |
|---|---|---|---|---|
| SELECT amount, status FROM orders WHERE id = :id | 1 | 5.52 | 181 | 0 |
| same | 8 | 41.7 | 192 | 0 |
| SELECT status, count(*), sum(amount) FROM orders GROUP BY status | 1 | 5.64 | 177 | 0 |
| same | 8 | 42.2 | 190 | 0 |
| INSERT INTO orders … VALUES (…) (one row) | 1 | 1.06 | 947 | 0 |
| same | 8 | 6.80 | 1 176 | 0 |
Average latency, ms, log scale
One client and eight clients per statement; simple protocol
Before and during this run
- The gateway ufgw (PostgreSQL wire protocol, simple protocol), token login checked at the gateway and at the node, a hidden tenant column, and the first SQL subset.
What the numbers say
The report's own reading, including what went wrong and what is still open.
- A primary-key lookup costs as much as a full GROUP BY. There was no key seek yet: every plan read the tenant's whole key range and filtered. For OLTP this was the first thing to fix (P3b).
- Queries do not scale with clients. ufd ran every request on one engine thread, so 8 clients got the same throughput as 1 with 8× the latency. Concurrent read execution at a snapshot is the second item.
- The gateway path itself is cheap: a one-row insert, which also fetches the catalog, parses and binds, takes about 1 ms end to end.
Files and tools
Report
docs/bench/2026-10-23-p3a-sql.md in the repository.
Raw results
No separate raw file; the figures are those printed by pgbench in the run and recorded in the report.
Access
The repository is private during development. Early-access teams receive the build, the benchmark scripts and the raw files.
See the measurements in context.
The performance page draws the latest figure from each area and states what is not measured yet.