{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifodyylwazqihpbq6xihbcc3xmztfrs6bfgw3ak2g4k5er3pzjd4a",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3monhslrmx522"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihd2rjvuvsn4o423lmxu35zdr4zsdiuubnmqoiix367liife5c3gu"
    },
    "mimeType": "image/webp",
    "size": 26100
  },
  "path": "/gajus/compile-zod-30x-faster-zod-validation-3kih",
  "publishedAt": "2026-06-19T13:23:35.000Z",
  "site": "https://dev.to",
  "tags": [
    "zod",
    "webperf",
    "performance",
    "100-600x",
    "zod-compiler",
    "@__PURE__"
  ],
  "textContent": "Lets start with a code example:\n\n\n\n    import { pool, sql } from \"./db.js\";\n    import { z } from \"zod\";\n\n    const getUser = (id: number) => {\n      return pool.one(\n        sql.type(\n          z.object({\n            id: z.number(),\n            name: z.string(),\n          }),\n        )`SELECT id, name FROM users WHERE id = ${id}`,\n      );\n    };\n\n\nThere are two performance issues in the above code:\n\n  1. `z.object({})` initialization\n  2. data validation using Zod parser (interpretation)\n\n\n\n##  Initialization\n\nThe first one is something you can solve simply by writing a code that avoid re-initialization, e.g.,\n\n\n\n    import { pool, sql } from \"./db.js\";\n    import { z } from \"zod\";\n\n    const UserZodSchema = z.object({\n      id: z.number(),\n      name: z.string(),\n    });\n\n    const getUser = (id: number) => {\n      return pool.one(sql.type(UserZodSchema)`SELECT id, name FROM users WHERE id = ${id}`);\n    };\n\n\nThis alone will increase your validation throughput by 100-600x (depending on the complexity of the schema).\n\nHowever, I would argue that changing code (assigning unnecessary variables) just so gain performance improvements is bad DX.\n\nInstead, you should be able to write code however you like, and your tooling should re-organize it in whatever way that makes the code run optimally.\n\n##  Interpretation\n\nWhen you call `UserZodSchema.parse(row)`, Zod walks the schema like an interpreter walks a syntax tree. A lot happens – and almost none of it depends on `row`:\n\n  * A fresh parse context and a root payload `{ value, issues: [] }` are allocated, including an issues array you'll almost never read.\n  * The result is checked against `instanceof Promise` – every synchronous parse pays a tax for the possibility of being async.\n  * For each property, another `{ value: input[key], issues: [] }` payload is allocated and `el._zod.run(...)` dispatches into the child – a string here, a number there, a nested object next. It's megamorphic; the engine can't specialize it.\n  * Each child recurses, allocating its own payload and its own issues array.\n\n\n\nNone of that depends on the data. It depends on the _shape_ of the schema – and the shape was fixed the moment\nyou wrote `z.object({ id: z.number(), name: z.string() })`. Zod re-discovers that shape on every single call.\n\nThat's the tell: Zod is a tree-walking interpreter. The schema is a data structure that describes validation; `.parse()` is the interpreter that walks it at runtime. Like every interpreter, it pays for its generality – indirection, allocation, dynamic dispatch – over and\nover, for a shape that never changes.\n\n\"But Zod v4 compiles objects!\" It does, and it's clever about it: `$ZodObjectJIT` uses `new Function` to generate a flattened parse routine the first time you call it. It helps – but read what it emits and you hit the ceiling:\n\n  * It's gated on `allowsEval`. Under a strict `Content-Security-Policy` (no `unsafe-eval`) – the norm for a lot of frontends and edge runtimes – it silently falls back to the interpreted path.\n  * It's generated lazily and in-process: on the first parse, in your process, on your hot path's first hit.\n  * It flattens one level only. Every property still goes through `shape[key]._zod.run({ value: input[key], issues: [] }, ctx)` – still a payload allocation, still a dynamic dispatch into the child.\n  * It still builds a fresh result object and copies every key into it on success.\n\n\n\nIt narrows the gap. It can't close it: the work is still happening at runtime, in your process, on every call.\n\n##  Compiling the parser\n\nWe just did this. Hoisting took schema _construction_ – work that doesn't depend on the input – and lifted it out of the hot path. Interpretation is the same problem one level deeper: walking the schema doesn't depend on the input either. So lift it out too, all the way out, to build time.\n\nThe shape is known when you write it. A compiler can read it once, ahead of time, and emit the exact validator: no tree to walk, no dispatch, no per-node payloads. Turn the data structure that describes the work into the code that does the work. That's just... what a compiler is.\n\nThat's zod-compiler. Same deal as hoisting – you keep writing plain Zod, the tooling reorganizes it. Drop it into your bundler:\n\n\n\n    // vite.config.ts\n    import zodCompiler from \"zod-compiler/vite\";\n\n    export default defineConfig({\n      plugins: [zodCompiler()],\n    });\n\n\nNo imports in your source. No wrappers. No `compile(...)`. The exact slonik snippet we started with – schema defined inline, anonymous, never exported – compiles to this (lightly trimmed):\n\n\n\n    import { __zcFin, __zcFinD, __zcIT, __zcMkv } from \"virtual:zod-compiler/runtime\";\n\n    const _zh_6c9cb1a3 = /* @__PURE__ */ (() => {\n      function __fc_0(input) {\n        return (\n          typeof input === \"object\" &&\n          input !== null &&\n          !Array.isArray(input) &&\n          Number.isFinite(input[\"id\"]) &&\n          typeof input[\"name\"] === \"string\"\n        );\n      }\n      function __sw_2(input) {\n        var _e = [];\n        /* error-collecting walk – runs only when .error is read */ return _e;\n      }\n      function safeParse__zh_6c9cb1a3(input) {\n        if (__fc_0(input)) {\n          return { success: true, data: input };\n        }\n        return __zcFinD(__sw_2, input);\n      }\n      return __zcMkv(\n        safeParse__zh_6c9cb1a3,\n        z.object({\n          id: z.number(),\n          name: z.string(),\n        }),\n        __fc_0,\n      );\n    })();\n\n    import { pool, sql } from \"./db.js\";\n    import { z } from \"zod\";\n\n    const getUser = (id: number) => {\n      return pool.one(sql.type(_zh_6c9cb1a3)`SELECT id, name FROM users WHERE id = ${id}`);\n    };\n\n\nRead it bottom-up:\n\n  * The real Zod schema is still constructed – once, at module load. `__zcMkv` installs the compiled methods onto it and returns it, so `sql.type()` receives a genuine Zod schema (identity, `.shape`, `._zod`, Standard Schema all intact) that just happens to validate fast.\n  * `__fc_0` is the fast path: one boolean expression for the entire input. No `_zod.run`, no payload objects, no issues arrays. A valid row returns `{ success: true, data: input }` – the input, by reference. Zero allocation.\n  * `__sw_2` and `__zcFinD` are the slow path: an invalid row returns `{ success: false }` immediately, and the error-collecting walk runs lazily – only if you actually read `.error`.\n  * It's plain generated code in your bundle – no `new Function`, no eval. CSP can't switch it off.\n\n\n\nOn that exact pattern, schema construction + per-row validation drops from ~16,700ns to ~14ns per call – construction amortizes to module load (hoisting), per-row validation rides the fast path (compilation).\n\nAnd for validation alone, against Zod v4 (ops/s, higher is better):\n\nScenario | Zod v4 | zod-compiler | vs Zod v4\n---|---|---|---\nmedium object (valid) | 2.4M | 10.3M | 4.3x\nmedium object (invalid) | 80K | 15.5M | 194x\nlarge object (100 keys) | 19K | 1.4M | 73x\n\nThe invalid-input row is the eye-catcher, and it's exactly the failure-deferral paying off: a failed `safeParse` never materializes the error until you read `.error`. The throwing `parse()` API rides the same zero-allocation fast path (medium object 2.3M → 9.7M).\n\nSo both costs are gone – and your source code never changed. You wrote the schema once, inline, the way that read best at the call site. The hoister moved its construction to module load; the compiler turned it into a flat, monomorphic, allocation-free validator at build time.\n\nYou write code however you like. Your tooling reorganizes it to run optimally.",
  "title": "Compile Zod (30x faster Zod validation)"
}