Benchmarks

Validation

zmdb registered as two participants in moltar/typescript-runtime-type-benchmarks and run by the upstream runner, one forked process per library, alongside the selected leaders ts-runtypes and ts-runtime-checks. zmdb is the runtime validator walking a descriptor; zmdb-aot is the same public API with the transformer applied, so the benchmarked code is transformer output rather than a hand-tuned lookalike.

All four cases at once

The same numbers without a tab in the way — useful because a library can win one case and lose another, and the tabbed view makes that easy to miss.

A dash means the case is unsupported. zmdb and zmdb-aot are excluded from parseSafe: the upstream contract requires a copy with unknown properties removed, while these APIs validate and return the input. The upstream runner measures repeated calls on one fixed object and discards returned values. It provides throughput and error margins, not individual-call p95/p99 latency.

ORM HTTP replay

k6 replay over the upstream drizzle-team/drizzle-benchmarks 13-route request list, comparing zmdb, Drizzle and Kysely. The corrected fixture uses matching projections and response shapes, one shared dataset and index set, and the same PostgreSQL service, pg driver and connection-pool size for every participant.

Route coverage

Throughput is only comparable between participants that answer the same routes. A participant that cannot express a route is marked missing here rather than being quietly dropped from the replay.

HTTP framework

Captured @zmdb/web and peer workloads under the the-benchmarker/web-frameworks shared contract — GET /, GET /user/:id, POST /user. zmdb runs on Node, Bun and Deno; the selected peers are Hono on Node and Deno, and Elysia on Bun. Each server uses one process on the same CPU.

Recorded runtimes: 3 — node v26.8.1: 1 worker, measured 2026-09-08T23:48:19.553Z; bun 1.4.0: 1 worker, measured 2026-09-08T23:48:19.553Z; deno deno 2.9.6 (stable, release, x86_64-unknown-linux-gnu) v8 15.0.245.2-rusty typescript 6.0.3: 1 worker, measured 2026-09-08T23:48:19.553Z.

Every candidate uses one server process, the same server CPU and separate load-generator CPUs. Saturation measures maximum throughput with closed-loop load; its latency is not coordinated-omission corrected. The fixed-rate capture offers 20,000 requests per second to every candidate and enables oha latency correction. Each displayed row keeps throughput and percentiles from the same median-throughput repetition. Brackets show the range of the three run summaries, not pooled percentiles or confidence intervals; raw downloads retain all repetitions.

Shared contract

Verified against every participant, ours included, before load is applied. A framework that fails this is not measured — a fast wrong answer is not a result.

Repository and relation loading

Current generated schemas, the same PostgreSQL data and indexes, pg driver and pool of 12 connections. The nested workload returns 25 users, 100 posts and 300 comments. Kysely and the zmdb builder use three queries and the same assembler; repository and deferred loading use the public repository APIs. Native Drizzle uses one relational query with JSON aggregation. Result equality is checked before timing.

Each row is the median-throughput repetition with its own p95/p99, followed by the throughput range across all three repetitions. These are closed-loop client-operation latencies, without coordinated-omission correction.

lookup · 1 concurrent operations

nested · 1 concurrent operations

lookup · 48 concurrent operations

nested · 48 concurrent operations

Latest optimizations — 9 September 2026 (Asia/Kolkata)

Before/after measurements of the changes integrated in 4c9cf2f4, using 9c8c206f as the baseline. These short, sequential runs compare zmdb with itself. They do not update competitor rankings or establish an industry-wide lead.

AMD Ryzen 7 7840U; Node 26.8.1, Bun 1.4.0, Deno 2.9.6; project compiler TypeScript 7.0.2; PostgreSQL 18.6, pg 8.23.0; oha 1.16.0. One application process on logical CPU 4. Timed runs were sequential with no concurrent owned builds or tests; ordinary desktop services remained running.

Values in brackets are observed sample ranges, not confidence intervals. The p99 columns show ranges of individual run percentiles; they are not pooled percentiles.

Serialization and generated validation

Five 80 ms samples per case and version, alternating order after 150 ms warmup, using the same 32 rotating inputs and consumed outputs. Lower time is better. These are the actual generated predicates and public serializer; no peer implementation was loaded.

Native serialization took 53–55% less time on these inputs. Numeric-validation differences were small and several sample ranges overlap; no general validator speedup is established.

HTTP and request data

Two four-second samples per version after one-second warmup, in before/after/after/before order, at 64 connections with keep-alive. One server process on CPU 4; client on CPUs 10, 12 and 14. Closed-loop maximum throughput; latency is not coordinated-omission corrected.

These results combine Fetch header/response conversion and the shared lazy request-data getter; their individual contributions are not isolated. Node throughput ranges and Bun p99 ranges overlap. The bounded request-body reader is unchanged.

Nested relation loading

Two four-second samples per version after one-second warmup, in before/after/after/before order, at concurrency 48 with a 12-connection pg pool. Each read returns 25 users, 100 posts and 300 comments in three queries. Medians of two samples are their midpoint. PostgreSQL runs on CPUs 6–11 on the same machine.

Repository throughput increased about 10% in this probe. Deferred results were more variable, and neither lane establishes a consistent p99 improvement.

Database comparison fairness

The corrected 13-route ORM fixture uses matching projections, response structures, data, driver and pool settings across zmdb, Drizzle and Kysely. Both full-text GIN indexes are created by the shared seed and are available to every participant. All 27 functional response-parity cases passed, and PostgreSQL selected both indexes. This is a correctness result, not a newly measured peer ranking.

Summary and provenance (JSON) · Per-run measurements and source hashes (gzip JSON) · Earlier comparative benchmarks and profiling report

The linked investigation measured revision 07b3ec80 before these optimizations. Its peer comparisons and experimental ablations retain their original conditions; experimental gains are not substituted for the implemented measurements above.

Engineering costs — earlier capture

Recorded zmdb measurements at revision cd6cdcc965a38d6ddc5b40a91b30f2f66bde4571. Each row uses the committed metric name, unit, median and min–max range. Values are displayed to three decimal places; full precision and every sample are available in the downloads.

Repeated current-revision zmdb measurements. Every sample is retained; summaries report median and range. Clean build means no emitted output; cached build retains filesystem/dependency caches. OS caches are not flushed. Compiler and installation tools are included in consumer size. PostgreSQL and load generator share this machine. No competitor reruns or comparative ranking.

OS caches are warm or unflushed, including clean-build runs; this capture does not measure a cold OS cache. PostgreSQL and the load generator are co-located. These zmdb-only results are separate from the historical competitor, PostgreSQL 16, Bun and Deno measurements below.

Summary and per-metric samples (JSON) · Complete raw runs and command output (gzip JSON) · Aggregation and metric definitions

Editor and compiler

Public product and server-core consumer projects: language-service operations and clean, incremental and affected-edit compilation. Measurement source.

Build, package and consumer

Clean builds remove emitted output; cached builds repeat the same build command with filesystem and dependency caches retained. Installed size and package count include TypeScript and installation tooling. Measurement source.

Startup and first work

Separate application initialization, process readiness, first HTTP request, first application query through SQLite and shutdown intervals. Measurement source.

PostgreSQL replay

zmdb-only HTTP replay. Latency medians and p90/p95/p99 rows are medians of per-run percentiles; they are not percentiles of a pooled request distribution. The range is the minimum and maximum run summary. Measurement source.

Reproduce this workload

Use an idle machine, a fresh work directory outside the repository, an installed k6 executable and a PostgreSQL server seeded with the Northwind loader. The capture records: node benchmarks/scripts/baseline.mjs --work-dir <outside-workspace> --rounds 7 (K6 and PGURL must identify the load generator and seeded PostgreSQL server).

K6=/absolute/path/to/k6 PGURL='postgres://user:password@localhost:55432/bench' \
  node benchmarks/scripts/baseline.mjs --work-dir ../zmdb-engineering-run --rounds 7
node --import ./scripts/ts-specifier-hook.mjs docs-site/build.mjs

The baseline script invokes the linked editor/compiler, lifecycle and PostgreSQL workloads and retains all rounds. The docs build renders the committed files. See the reproduction guide for setup and individual diagnostic commands.