Vercel unifica Data Cache e Runtime Cache para simplificar o Runtime Caching

A Vercel está incorporando o Data Cache ao Runtime Cache, e o resultado é um produto só para cache de dados entre frameworks e APIs. O Data Cache nasceu como o serviço de cache do App Router do Next.js, usado pelo cache de fetch e por unstable_cache. Ele guarda os dados que a aplicação usa para montar a resposta, não a resposta HTTP completa como faz o cache de CDN. Já o Runtime Cache chegou no ano passado com a API getCache, de @vercel/functions, e hoje também atende o 'use cache: remote' do Next.js. Com a migração, as quatro APIs passam a compartilhar o mesmo orçamento de armazenamento e as mesmas ferramentas de uso.

Por baixo, há uma API em Go com frotas de Redis em cada região da Vercel. O serviço processa mais de 440 milhões de leituras e move mais de 18 TB de dados por hora. Cada região tem seu cache, e um miss não consulta outras regiões. A invalidação funciona por tag: cada entrada guarda suas tags e o horário de escrita, e a leitura compara com o timestamp de invalidação num tag store da mesma região. Invalidar a tag grava um único timestamp, mesmo com um milhão de entradas. Esse timestamp chega às outras regiões em geral em poucas centenas de milissegundos. Para quem usa fetch caching ou unstable_cache, o código não muda. No plano Pro, cada projeto e ambiente ganha alocação própria, com 8x o espaço do pool de equipe anterior do Data Cache. No Enterprise, são 10x. Leituras e escritas do Data Cache que antes não eram cobradas passam a seguir o preço do Runtime Cache.

Em 30 de outubro de 2026, o CEVIU noticiou "Vercel unifica o Data Cache ao Runtime Cache e simplifica o cache em runtime", com o anúncio da unificação. Esta nova matéria traz o detalhamento técnico: a arquitetura regional com Redis, a invalidação por timestamp de tag, os circuit breakers ativados em agosto e os ganhos de armazenamento e cobrança.

Para quem opera apps Next.js na Vercel, a leitura é que o custo do cache passa a aparecer na fatura. Vale revisar o uso e o guia de otimização antes da migração, para cortar leituras e escritas desnecessárias. Quem usa SvelteKit ou Nuxt ganha um caminho de cache sem depender do Next.js. Um detalhe de projeto: durante o fallback dos circuit breakers, uma leitura pode tratar por pouco tempo um dado recém-invalidado como fresco.