Real numbers. Sourced. Re-run on every commit.

How the engine behaves at a thousand models.

05 — Production-grade proof suite

Tests that prove correctness under ugly cases.

Six suites · 37 / 37 passing · all run against a real Postgres database (PostgreSQL 17.8). The stress test compiles a 1,000-model schema with 3,967 directed relation edges. Type assertions are verified under tsc --noEmit, including negative cases via // @ts-expect-error. Crash-resume + recovery checksum tests use real data — every claim below is backed by a test you can re-run.

# 1. dedicated test database (idempotent)
psql -h localhost -d postgres \
  -c "DROP DATABASE IF EXISTS zanith_proof_tests" \
  -c "CREATE DATABASE zanith_proof_tests"

# 2. run the proof suite
npx vitest run test/proof/

# 3. (optional) confirm type assertions under tsc — vitest strips types
npx tsc --noEmit

SELECT "domain_0"."id", "domain_0"."slug"
FROM "domain_0" AS "domain_0"
WHERE "domain_0"."active" = TRUE
LIMIT $1
-- params: [10]

SELECT "chain0"."id" AS "topId",
       "next_5"."label" AS "deepestLabel"
FROM "chain0" AS "chain0"
LEFT JOIN "chain1" AS "next"   ON "chain0"."next_id"  = "next"."id"
LEFT JOIN "chain2" AS "next_2" ON "next"."next_id"    = "next_2"."id"
LEFT JOIN "chain3" AS "next_3" ON "next_2"."next_id"  = "next_3"."id"
LEFT JOIN "chain4" AS "next_4" ON "next_3"."next_id"  = "next_4"."id"
LEFT JOIN "chain5" AS "next_5" ON "next_4"."next_id"  = "next_5"."id"

SELECT "domain_0"."id",
       "createdBy"."email" AS "creator",
       "updatedBy"."email" AS "updater",
       "approvedBy"."email" AS "approver"
FROM "domain_0" AS "domain_0"
LEFT JOIN "users" AS "createdBy"  ON "domain_0"."created_by_id"  = "createdBy"."id"
LEFT JOIN "users" AS "updatedBy"  ON "domain_0"."updated_by_id"  = "updatedBy"."id"
LEFT JOIN "users" AS "approvedBy" ON "domain_0"."approved_by_id" = "approvedBy"."id"
LIMIT $1
-- params: [5]

05 — What this page doesn't measure

The numbers above are real. Here's what they aren't.

Per the VOICE.md disclaimer rule: every claim made on this page has an accompanying caveat about what the figure does and does not cover. Four gaps, listed plainly so the credibility is shaped by the absence too.

• Gap · 01scope · by design

  End-to-end query time against a live database

  Every µs on this page is engine overhead. Network latency, connection setup, and the database's actual execution time are excluded. If you want end-to-end numbers, the local benchmark setup in §06 will produce them.

• Gap · 02in progress

  Comparable benchmarks against Prisma, Drizzle, TypeORM

  We don't have sourced competitor figures yet. Until we do, the marketing copy uses one consistent hedge: "codegen ORMs at this scale spend minutes regenerating." Specific µs comparisons will land when we can run a matched workload on each.

• Gap · 03planned

  Long-running memory churn

  The 3.4MB figure is the steady-state graph footprint. We haven't yet measured what happens to memory under continuous schema reloads, sustained query throughput, or under-leak-detection runs over hours.

• Gap · 04downstream concern

  Performance on hot-paths inside the DB

  The compiler's choice of joins, projections, and parameter shapes affects how the database plans the query. We measure what we emit, not how the planner reacts. The /examples page shows the SQL we generate; production tuning lives downstream.