Lets start with a code example:

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

const getUser = (id: number) => {
  return pool.one(
    sql.type(
      z.object({
        id: z.number(),
        name: z.string(),
      }),
    )`SELECT id, name FROM users WHERE id = ${id}`,
  );
};

There are two performance issues in the above code:

1. z.object({}) initialization
2. 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";
import { z } from "zod";

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

const getUser = (id: number) => {
  return pool.one(sql.type(UserZodSchema)`SELECT id, name FROM users WHERE id = ${id}`);
};

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
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
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
import zodCompiler from "zod-compiler/vite";

export default defineConfig({
  plugins: [zodCompiler()],
});

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

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

const getUser = (id: number) => {
  return pool.one(sql.type(_zh_6c9cb1a3)`SELECT id, name FROM users WHERE id = ${id}`);
};

Read it bottom-up:

• 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.
• __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.
• __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.
• It's plain generated code in your bundle – no new Function, no eval. CSP can't switch it off.

On 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).

And for validation alone, against Zod v4 (ops/s, higher is better):

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

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

You write code however you like. Your tooling reorganizes it to run optimally.