Compile Zod (30x faster Zod validation)Lets start with a code example:

import { pool, sql } from "./db.js";<br>import { z } from "zod";

const getUser = (id: number) => {<br>return pool.one(<br>sql.type(<br>z.object({<br>id: z.number(),<br>name: z.string(),<br>}),<br>)`SELECT id, name FROM users WHERE id = ${id}`,<br>);<br>};<br>There are two performance issues in the above code:

z.object({}) initialization

data validation using Zod parser (interpretation)

Initialization

The first one is something you can solve simply by writing a code that avoid re-initialization, e.g.,

import { pool, sql } from "./db.js";<br>import { z } from "zod";

const UserZodSchema = z.object({<br>id: z.number(),<br>name: z.string(),<br>});

const getUser = (id: number) => {<br>return pool.one(sql.type(UserZodSchema)`SELECT id, name FROM users WHERE id = ${id}`);<br>};<br>This alone will increase your validation throughput by 100-600x (depending on the complexity of the schema).

However, I would argue that changing code (assigning unnecessary variables) just so gain performance improvements is bad DX.

Instead, 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.

Interpretation

When 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:

A fresh parse context and a root payload { value, issues: [] } are allocated, including an issues array you'll almost never read.

The result is checked against instanceof Promise – every synchronous parse pays a tax for the possibility of being async.

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.

Each child recurses, allocating its own payload and its own issues array.

None of that depends on the data. It depends on the shape of the schema – and the shape was fixed the moment<br>you wrote z.object({ id: z.number(), name: z.string() }). Zod re-discovers that shape on every single call.

That'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<br>over, for a shape that never changes.

"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:

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.

It's generated lazily and in-process: on the first parse, in your process, on your hot path's first hit.

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.

It still builds a fresh result object and copies every key into it on success.

It narrows the gap. It can't close it: the work is still happening at runtime, in your process, on every call.

Compiling the parser

We 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.

The 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.

That's zod-compiler. Same deal as hoisting – you keep writing plain Zod, the tooling reorganizes it. Drop it into your bundler:

// vite.config.ts<br>import zodCompiler from "zod-compiler/vite";

export default defineConfig({<br>plugins: [zodCompiler()],<br>});<br>No 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):

import { __zcFin, __zcFinD, __zcIT, __zcMkv } from "virtual:zod-compiler/runtime";

const _zh_6c9cb1a3 = /* @__PURE__ */ (() => {<br>function __fc_0(input) {<br>return (<br>typeof input === "object" &&<br>input !== null &&<br>!Array.isArray(input) &&<br>Number.isFinite(input["id"]) &&<br>typeof input["name"] === "string"<br>);<br>function __sw_2(input) {<br>var _e = [];<br>/* error-collecting walk – runs only when .error is read */ return _e;<br>function safeParse__zh_6c9cb1a3(input) {<br>if (__fc_0(input)) {<br>return { success: true, data: input };<br>return __zcFinD(__sw_2, input);<br>return __zcMkv(<br>safeParse__zh_6c9cb1a3,<br>z.object({<br>id:...