Dev & EngNOTÍCIA

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

A versão 4.5 do Zod, lançada em agosto de 2026, adiciona z.compile() para compilar schemas sem passo de build e reduz o consumo de memória de cada schema em até nove vezes; a 4.6, de setembro, corrige uma regressão séria e acelera ainda mais a rejeição de dados inválidos.

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

O Zod, biblioteca de validação de schemas TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) →-first criada por Colin McDonnell, lançou a versão 4.5 em 28 de agosto de 2026 com um conjunto de mudanças de performance e memória. A versão 4.6 seguiu em 9 de setembro de 2026, estendendo esse trabalho e corrigindo uma regressão de memória em schemas recursivos. Os números mais relevantes, de compilação e footprint, chegaram na 4.5, mas quem for atualizar agora precisa olhar também para o que a 4.6 ajustou (InfoQ).

Um compilador que roda dentro do processo, sem passo de build

A novidade central é z.compile(), que transforma qualquer schema num validador pré-compilado capaz de processar o mesmo dado de três a nove vezes mais rápido, mantendo o comportamento idêntico ao schema original, sem regra especial de uso. Como explicou McDonnell, a compilação acontece in-process, e não em build time, então não há plugin de bundler nem passo de codegen para configurar.

Para aplicar isso a um projeto inteiro, basta importar zod/compile no topo do ponto de entrada da aplicação, ou rodar node --import zod/compile app.js. A partir daí, cada schema é compilado de forma preguiçosa na primeira vez que processa um dado.

Quanto cai o uso de memória, em números

A mudança técnica por trás do ganho é a memoização de métodos vinculados em vez de alocá-los por instância. Um z.string() simples, que antes retinha 7,5kb de heap, agora retém 784 bytes: uma redução de aproximadamente nove vezes. O safeParse() também passou a pular a captura de stack trace em caso de falha, o que torna rejeitar uma entrada inválida cerca de 7,5 vezes mais barato.

Para quem roda validação em ambientes com memória limitada, como funções serverless com cold start, Edge Functions da Vercel ou Cloudflare Workers, esse corte de memória por schema não é cosmético: é a diferença entre uma função que estoura o limite de heap sob carga e uma que não estoura, especialmente em APIs que instanciam muitos schemas por requisição.

Zod 4.6: validate() booleano e correção de um bug sério

A adição mais relevante da 4.6 é .validate(), uma checagem puramente booleana que evita construir um resultado de parse ou um ZodError e pode parar no primeiro erro encontrado. Com a compilação habilitada, a InfoQ reporta melhoria de até 35 vezes sobre .safeParse().success ao validar entrada inválida. Não é um ganho geral de parsing nem substitui o safeParse() quando o código precisa do dado transformado ou dos detalhes do erro.

A 4.6 também traz validação de propriedades em instâncias de classe, seis novas palavras-chave de validação em z.fromJSONSchema(), e z.iban(). Para ambientes cuja Content Security Policy bloqueia o new Function usado internamente por z.compile(), existe z.withParser(), que instala um parser gerado externamente, mas não gera esse parser sozinho.

O ponto que mais importa para quem já adotou a 4.5 é outro: a 4.6 corrige uma regressão que retinha dados já processados em schemas recursivos e podia causar falhas de memória insuficiente (out-of-memory). Quem subiu direto para a 4.5 e usa schemas recursivos deveria migrar para a 4.6 sem demora.

Outras adições da 4.5 que não são sobre performance

Além da compilação, a 4.5 trouxe um pacote de helpers pedidos há tempo pela comunidade:

  • z.deepPartial() voltou a existir, depois de ter sido removido em versões anteriores do Zod 4
  • .exactPartial() como nova forma de tornar campos parciais
  • z.creditCard() para validação de número de cartão
  • z.input() e z.output() para inferir os tipos de entrada e saída de um schema
  • suporte a dados cíclicos em schemas recursivos
  • oito novos locales de erro

Como o Zod compara com Typia, Valibot e ArkType agora

No benchmark Moltar parseSafe citado no anúncio da 4.5, o Zod compilado atinge 47,5 milhões de operações por segundo, à frente do Typia (45,3 milhões) e muito à frente de Valibot (1,8 milhão) e ArkType (152 mil):

Gráfico do benchmark Moltar parseSafe mostra Zod 4 compilado com 47,5 milhões de operações por segundo, à frente de Typia (45,3M), Zod 4 não compilado (11,6M), Valibot (1,8M), Effect (1,7M), Zod 3 (1,2M), ArkType (152k) e Yup (121k)
Gráfico do benchmark Moltar parseSafe mostra Zod 4 compilado com 47,5 milhões de operações por segundo, à frente de Typia (45,3M), Zod 4 não compilado (11,6M), Valibot (1,8M), Effect (1,7M), Zod 3 (1,2M), ArkType (152k) e Yup (121k). Reprodução: infoq.com.
BibliotecaOps/seg (Moltar parseSafe)
Zod (compilado)47,5 milhões
Typia45,3 milhões
Valibot1,8 milhão
ArkType152 mil

É uma guinada notável diante de um concorrente que há anos se vende como várias vezes mais rápido que o Zod. Mas o quadro não é unânime: no benchmark de checagem booleana publicado junto com a 4.5, Typia e ArkType ficaram à frente do Zod compilado. Esses números são uma fotografia daquele release, não uma comparação nova contra o .validate() da 4.6, e qual biblioteca é mais rápida continua dependendo da carga de trabalho.

O desenvolvedor Mehul Mohan descreveu o ganho de cerca de dez vezes em objetos e arrays da seguinte forma:

Uma vitória real de performance.

a real performance winMehul Mohan, desenvolvedor

O que muda pra quem roda Node ou Edge no Brasil

O Zod hoje passa de 30 milhões de downloads semanais e tem suporte de primeira classe em tRPC, React Hook Form e boa parte dos frameworks de backend do ecossistema JavaScript. É difícil achar um time brasileiro usando TypeScript em produção que não dependa dele em algum ponto da stack, direto ou via alguma dessas ferramentas.

Para quem roda em ambiente com restrição de recursos (containers com limite de memória apertado, funções serverless cobradas por tempo e memória alocada, Edge runtimes), o corte de 9x no footprint de cada schema é o tipo de mudança que aparece na fatura de cloud, não só no benchmark. Vale medir o impacto antes e depois da ativação de z.compile() num serviço que valida muitos schemas por requisição.

Dois cuidados práticos antes de atualizar: times que usam schemas recursivos devem ir direto para a 4.6, por causa da regressão de memória corrigida ali, e quem roda em ambiente com CSP restritiva (comum em bancos e setor público) precisa confirmar se new Function é permitido ou se vai precisar de z.withParser() com um parser gerado fora do processo.

Fonte: InfoQ

Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.

O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.

Mais de Redação iMasters
Ver perfil →
Leia também
Figma Config India

Figma lança editor de design para guiar agentes de IA no Config India

Na primeira edição do Config na Índia, o Figma apresentou o Figma Specs, editor em Markdown que documenta regras de design para times e para os agentes que já operam no canvas, além de tirar o recurso de código do protótipo da fase fechada de testes.

Redação iMasters··1 min