NEWS

Zod 4.5 traz compilação de schema in-process e corta uso de memória em 9 vezes

Zod 4.5, released in August 2026, adds z.compile() to compile schemas with no build step and cuts each schema's memory footprint by up to nine times; 4.6, in September, fixes a serious regression and makes rejecting invalid data even faster.

Zod 4.5 traz compilação de schema in-process e corta uso de memória em 9 vezes
Image: Redação iMasters

Zod, the TypeScript-first schema validation library created by Colin McDonnell, released version 4.5 on August 28, 2026, with a set of performance and memory changes. Version 4.6 followed on September 9, 2026, extending that work and fixing a memory regression in recursive schemas. The most relevant numbers, on compilation and footprint, came in 4.5, but anyone updating now also needs to look at what 4.6 fixed (InfoQ).

A compiler that runs inside the process, with no build step

The central new feature is z.compile(), which turns any schema into a pre-compiled validator capable of processing the same data three to nine times faster, while keeping behavior identical to the original schema, with no special usage rules. As McDonnell explained, compilation happens in-process, not at build time, so there's no bundler plugin or codegen step to configure.

To apply this to an entire project, just import zod/compile at the top of the application's entry point, or run node --import zod/compile app.js. From there, each schema is lazily compiled the first time it processes a piece of data.

How much memory usage drops, in numbers

The technical change behind the gain is memoizing bound methods instead of allocating them per instance. A simple z.string(), which used to retain 7.5KB of heap, now retains 784 bytes: a reduction of roughly nine times. safeParse() also now skips capturing a stack trace on failure, which makes rejecting invalid input about 7.5 times cheaper.

For anyone running validation in memory-constrained environments, like serverless functions with cold starts, Vercel Edge Functions or Cloudflare Workers, this per-schema memory cut isn't cosmetic: it's the difference between a function that blows past the heap limit under load and one that doesn't, especially in APIs that instantiate many schemas per request.

Zod 4.6: boolean validate() and a fix for a serious bug

The most relevant addition in 4.6 is .validate(), a purely boolean check that avoids building a parse result or a ZodError and can stop at the first error found. With compilation enabled, InfoQ reports an improvement of up to 35 times over .safeParse().success when validating invalid input. It's not a general parsing gain, nor does it replace safeParse() when the code needs the transformed data or the error details.

4.6 also brings property validation on class instances, six new validation keywords in z.fromJSONSchema(), and z.iban(). For environments whose Content Security Policy blocks the new Function used internally by z.compile(), there's z.withParser(), which installs an externally generated parser but doesn't generate that parser on its own.

The point that matters most for anyone who already adopted 4.5 is different: 4.6 fixes a regression that retained already-processed data in recursive schemas and could cause out-of-memory failures. Anyone who jumped straight to 4.5 and uses recursive schemas should migrate to 4.6 without delay.

Other 4.5 additions that aren't about performance

Beyond compilation, 4.5 brought a package of helpers the community had long been asking for:

  • z.deepPartial() exists again, after being removed in earlier Zod 4 versions
  • .exactPartial() as a new way to make fields partial
  • z.creditCard() for credit card number validation
  • z.input() and z.output() to infer a schema's input and output types
  • support for cyclic data in recursive schemas
  • eight new error locales

How Zod compares with Typia, Valibot and ArkType now

In the Moltar parseSafe benchmark cited in the 4.5 announcement, compiled Zod reaches 47.5 million operations per second, ahead of Typia (45.3 million) and well ahead of Valibot (1.8 million) and ArkType (152 thousand):

Chart from the Moltar parseSafe benchmark shows compiled Zod 4 at 47.5 million operations per second, ahead of Typia (45.3M), uncompiled Zod 4 (11.6M), Valibot (1.8M), Effect (1.7M), Zod 3 (1.2M), ArkType (152k) and Yup (121k)
Chart from the Moltar parseSafe benchmark shows compiled Zod 4 at 47.5 million operations per second, ahead of Typia (45.3M), uncompiled Zod 4 (11.6M), Valibot (1.8M), Effect (1.7M), Zod 3 (1.2M), ArkType (152k) and Yup (121k). Reprodução: infoq.com.
LibraryOps/sec (Moltar parseSafe)
Zod (compiled)47.5 million
Typia45.3 million
Valibot1.8 million
ArkType152 thousand

It's a notable turnaround against a competitor that has marketed itself for years as several times faster than Zod. But the picture isn't unanimous: in the boolean-check benchmark published alongside 4.5, Typia and ArkType came out ahead of compiled Zod. These numbers are a snapshot of that release, not a new comparison against 4.6's .validate(), and which library is faster still depends on the workload.

Developer Mehul Mohan described the roughly tenfold gain on objects and arrays like this:

a real performance win

Mehul Mohan, developer

What changes for teams running Node or Edge in Brazil

Zod now surpasses 30 million weekly downloads and has first-class support in tRPC, React Hook Form and much of the JavaScript ecosystem's backend frameworks. It's hard to find a Brazilian team running TypeScript in production that doesn't depend on it somewhere in the stack, directly or through one of these tools.

For anyone running in resource-constrained environments (containers with tight memory limits, serverless functions billed by time and allocated memory, Edge runtimes), the 9x cut in each schema's footprint is the kind of change that shows up on the cloud bill, not just in the benchmark. It's worth measuring the impact before and after enabling z.compile() in a service that validates many schemas per request.

Two practical cautions before updating: teams using recursive schemas should go straight to 4.6, because of the memory regression fixed there, and anyone running in an environment with restrictive CSP (common in banks and the public sector) needs to confirm whether new Function is allowed or whether they'll need z.withParser() with a parser generated outside the process.

Translated from the Brazilian Portuguese original · Read the original