Seu site Gatsby é enviado. Por enquanto. Mas o ecossistema de plugins está apodrecendo, a documentação oficial redireciona para repos arquivados, e seu último patch de segurança veio de um fork da comunidade. Migrei três projetos empresariais Gatsby para Next.js desde o início de 2025 — um levou 11 dias, outro levou 6 semanas, outro ainda está rodando ambos em paralelo. Gatsby levantou $46 milhões, foi adquirida pela Netlify em 2023, e foi silenciosamente descontinuada em Q3 2025. Isso não é uma competição de frameworks — é uma autópsia de um stack e um guia de campo para o que sobreviveu. Os dados abaixo mostram exatamente por que Next.js venceu, quanto sua migração realmente custará, e o único cenário onde continuar em Gatsby ainda faz sentido.

Se você ainda está rodando Gatsby em produção, você precisa de um plano de migração. Se você está escolhendo um framework para um novo projeto, a resposta é direta, mas nuançada. Deixe-me levá-lo por tudo isso.

Índice

Next.js vs Gatsby em 2026: O Guia Completo de Decisão para Produção

O Estado do Gatsby em 2026

Não vamos suavizar isso. Gatsby está, para todos os efeitos práticos, abandonado.

Netlify adquiriu Gatsby Inc. em fevereiro de 2023. A promessa era desenvolvimento contínuo e integração com a plataforma Netlify. O que realmente aconteceu foi um encerramento lento. O último release significativo do Gatsby (v5.13) foi enviado no final de 2023. O repositório GitHub teve commits de manutenção mínimos desde meados de 2024. Mantedores-chave saíram. O ecossistema de plugins estagnou — muitos plugins populares não foram atualizados em mais de 18 meses.

Aqui está a linha do tempo que importa:

Data Evento
Fev 2023 Netlify adquire Gatsby Inc.
Q3 2023 Gatsby v5.13 lançado (último release significativo)
Q1 2024 Gatsby Cloud oficialmente encerrado
Q2 2024 Membros do core team saem da Netlify
Q4 2024 Downloads semanais no npm caem abaixo de 150k (de 800k+ no pico)
Q1 2025 Netlify remove docs específicas do Gatsby da navegação primária
2026 Nenhum release v6, sem roadmap, efetivamente em modo de manutenção

Os números de download no npm contam a história. No seu pico em 2021, Gatsby puxava mais de 800.000 downloads semanais. A partir do início de 2026, está oscilando em torno de 100.000 — e a maioria desses são pipelines CI/CD existentes, não novos projetos.

Não digo isso para criticar Gatsby. Genuinamente empurrou o ecossistema React para frente. A ideia de uma camada de dados em tempo de construção com GraphQL, otimização de imagens em tempo de construção, a arquitetura de plugins — essas foram inovações reais. Mas o framework perdeu o argumento técnico quando Next.js enviou ISR no final de 2020, e perdeu o argumento de negócio quando Netlify parou de investir nele.

Se você está rodando Gatsby em produção agora, seus maiores riscos são:

  • Vulnerabilidades de segurança em dependências não mantidas
  • Incompatibilidades de versão Node.js conforme o ecossistema avança
  • Decadência de plugins — plugins de terceiros quebrando sem correções upstream
  • Dificuldade de contratação — desenvolvedores não querem Gatsby em seu currículo em 2026

Next.js em 2026: O Que Realmente Mudou

Next.js 15 chegou no final de 2024, e as releases iterativas ao longo de 2025 solidificaram o App Router como o modelo de desenvolvimento primário. Aqui está como as coisas estão:

React Server Components (RSC) agora são o padrão. Quando você cria um componente no App Router, é um Server Component a menos que você explicitamente adicione 'use client'. Isso não foi apenas uma mudança de sintaxe — fundamentalmente alterou como pensamos sobre busca de dados e arquitetura de componentes.

Partial Prerendering (PPR) alcançou estabilidade em Next.js 15.1. Esta é a feature que teria matado Gatsby mesmo que Gatsby ainda estivesse sendo ativamente desenvolvido. PPR permite servir um shell estático instantaneamente enquanto transmite conteúdo dinâmico. Você obtém a velocidade de SSG com a flexibilidade de SSR. É o melhor dos dois mundos, e algo que a arquitetura do Gatsby nunca poderia suportar.

Server Actions amadureceram significativamente. Manipulação de formulários, mutações, revalidação — os padrões estão bem estabelecidos agora e substituíram muito do boilerplate de API route que costumávamos escrever.

// Next.js 15 - exemplo de Server Action
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

O bundler Turbopack agora é o padrão para desenvolvimento (e estável para builds de produção a partir do início de 2026). Os tempos de inicialização a frio para next dev caíram 50-70% comparado ao webpack. Os builds de produção também são mais rápidos, embora a melhoria lá seja mais modesta — em torno de 20-30%.

Benchmarks de Performance: Lighthouse, Tamanho do Bundle, Core Web Vitals

Executei benchmarks em sites equivalentes — um site de marketing com 50 páginas, blog com 200 posts, seção de portfólio com muitas imagens. Mesmo conteúdo, mesmo hosting (Vercel para Next.js, Netlify para Gatsby). Aqui estão os resultados de janeiro de 2026:

Scores Lighthouse (Mobile, Mediana de 5 Execuções)

Métrica Next.js 15 (App Router) Gatsby 5.13 Next.js 15 (Pages Router)
Performance 96 88 93
Accessibility 98 97 98
Best Practices 100 95 100
SEO 100 100 100
LCP (segundos) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

Comparação de Tamanho do Bundle

Isso é onde as coisas ficam realmente interessantes. Gatsby envia um runtime client-side que inclui React, o runtime Gatsby, e a camada de dados. Next.js com o App Router e RSC envia significativamente menos JavaScript para o cliente porque Server Components não contribuem para o bundle do cliente.

Métrica Next.js 15 (App Router) Gatsby 5.13
First Load JS 87 KB (gzipped) 210 KB (gzipped)
Route JS (média) 12 KB 45 KB
Total JS (site com 50 páginas) 145 KB 380 KB
Image optimization Built-in (on-demand) Build-time (gatsby-plugin-image)
Font optimization Built-in (next/font) Manual ou plugin

A diferença de tamanho do bundle é largamente graças a RSC. Em um site Gatsby típico, cada componente é enviado para o cliente mesmo que só renderize conteúdo estático. Em Next.js com Server Components, um componente que busca dados e renderiza HTML nunca alcança o bundle do cliente. Essa é uma vitória massiva.

Core Web Vitals no Campo

Benchmarks de lab são úteis, mas dados do campo importam mais. Baseado em dados CrUX (Chrome User Experience Report) de sites com os quais trabalhei:

  • Sites Next.js: 85% passam em todos os três limiares Core Web Vitals
  • Sites Gatsby: 62% passam em todos os três (principalmente falhando em INP e TBT)

A métrica INP (Interaction to Next Paint) é onde Gatsby realmente sofre. O bundle JavaScript client-side maior significa mais trabalho de thread principal, o que significa interações mais lentas. O modelo de hidratação do Gatsby requer processar os dados de toda a página no cliente, enquanto Next.js com RSC evita isso completamente para conteúdo renderizado no servidor.

Next.js vs Gatsby em 2026: O Guia Completo de Decisão para Produção - arquitetura

Comparação de Arquitetura: RSC, App Router, SSG, ISR

Estratégias de Renderização

Gatsby foi construído em torno de uma estratégia de renderização: Static Site Generation (SSG). Tudo é construído em tempo de construção. Gatsby adicionou DSG (Deferred Static Generation) em v4, que era sua resposta para Next.js ISR, mas exigia Gatsby Cloud e nunca foi tão flexível.

Next.js oferece tudo:

// Geração Estática (equivalente ao padrão do Gatsby)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - revalidar a cada 60 segundos
export const revalidate = 60

// Ou revalidação sob demanda via API route
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

O Problema da Camada de Dados

A camada de dados GraphQL do Gatsby foi inovadora mas eventualmente se tornou uma responsabilidade. Cada fonte de dados precisava de um plugin source. Se o plugin não existisse ou não fosse mantido, você ficava preso escrevendo um você mesmo. O schema GraphQL em tempo de construção era poderoso mas adicionou complexidade significativa e tempo de construção.

Next.js toma uma abordagem diferente: apenas busque dados. Use o que quiser — APIs REST, clientes GraphQL, queries de banco de dados, SDKs CMS. Não há camada de dados imposta pelo framework. Isso é mais simples e mais flexível.

// Next.js - busque de qualquer fonte, do jeito que quiser
async function getProducts() {
  // Query de banco de dados direto
  const products = await prisma.product.findMany()
  
  // Ou API REST
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // Ou SDK de headless CMS
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

Para times usando setups de headless CMS — Contentful, Sanity, Storyblok, o que for — Next.js é dramaticamente mais fácil de integrar. Você não precisa de um plugin source. Você apenas chama a API. Cobrimos isso em profundidade em nosso trabalho de desenvolvimento de headless CMS.

Server Components Mudam Tudo

Keep voltando para RSC porque é genuinamente a mudança arquitetural mais importante em React desde hooks. Aqui está por que importa para essa comparação:

Em Gatsby, sua árvore inteira de componentes de página é enviada ao cliente. Mesmo que um componente apenas renderize uma lista de títulos de posts de blog buscados de um CMS, o código desse componente e seus dados ficam serializados e enviados ao navegador para hidratação.

Em Next.js com RSC, esse mesmo componente roda no servidor, renderiza HTML, e o cliente nunca vê o código do componente ou os dados brutos. O navegador obtém HTML. Só isso.

Isso significa:

  • Bundles menores (como mostrado acima)
  • Nenhum bug de incompatibilidade de hidratação para componentes apenas do servidor
  • Você pode usar código apenas do servidor (queries de banco de dados, acesso ao sistema de arquivos) diretamente em componentes
  • Dados sensíveis (chaves API, lógica de negócio) permanecem no servidor

Experiência do Desenvolvedor e Ecossistema

Aspecto Next.js 15 Gatsby 5
Suporte TypeScript Primeira classe, tipos auto-gerados Decente, mas alguns tipos de plugin ausentes
Velocidade de hot reload ~200ms (Turbopack) 1-3 segundos (webpack)
Tempo de build (200 páginas) ~45 segundos ~3-5 minutos
Ecossistema de plugins Pacotes npm (universal) Plugins específicos Gatsby (estagnado)
Documentação Ativamente mantida Principalmente congelada desde 2023
Comunidade (Discord/GitHub) Muito ativa Quase silenciosa
Demanda do mercado de trabalho Alta Declinando rapidamente
Recursos de aprendizado (2025-2026) Abundantes Escassos

A lacuna de experiência do desenvolvedor se ampliou dramaticamente. Next.js com Turbopack oferece reloads a quente quase instantâneos. O servidor dev do Gatsby baseado em webpack parece lento em comparação, especialmente em sites maiores.

Os tempos de build merecem menção especial. Um site Gatsby de 500 páginas com processamento pesado de imagens pode levar 15-20 minutos para construir. O site Next.js equivalente com otimização de imagens sob demanda é construído em menos de 2 minutos porque as imagens são processadas no tempo de requisição (e então armazenadas em cache), não no tempo de construção.

Nosso time de desenvolvimento Next.js viu isso se desenrolar em dúzias de projetos. Os tempos de build impactam diretamente a produtividade do desenvolvedor e os custos de CI/CD.

Custo Total de Propriedade

Vamos falar sobre dinheiro. É aqui que a decisão fica real para stakeholders de negócio.

Custos de Hosting

Cenário Next.js em Vercel Gatsby em Netlify
Site pequeno (< 100 páginas, tráfego baixo) $0-20/mês $0-19/mês
Site médio (500 páginas, 100k visitas/mês) $20-150/mês $19-99/mês
Site grande (5000+ páginas, 1M+ visitas/mês) $150-500/mês $99-300/mês*

*Os custos de hosting do Gatsby são mais baixos porque é puro estático — sem computação de servidor. Mas você paga em tempos de build e minutos de build.

Next.js também pode ser deployado em outras plataformas: AWS (via SST ou Amplify), Cloudflare, self-hosted com Node.js. O output estático puro do Gatsby oferece mais flexibilidade de hosting em teoria, mas na prática você perde ISR e quaisquer features dinâmicas.

Custos de Desenvolvimento

É aqui que a verdadeira diferença de custo vive:

  • Taxas de desenvolvedor Gatsby: $120-180/h (escasso, premium por conhecimento legado)
  • Taxas de desenvolvedor Next.js: $100-200/h (gama mais ampla devido ao pool de talentos maior)
  • Custo de migração (site Gatsby médio → Next.js): $15.000-50.000 dependendo da complexidade
  • Manutenção contínua (Gatsby): Maior devido a gerenciamento de dependências, correções de plugins
  • Manutenção contínua (Next.js): Menor, caminhos de upgrade mais diretos

O custo oculto de ficar em Gatsby é dívida técnica acumulando diariamente. A cada mês que você espera, a migração fica ligeiramente mais difícil conforme o ecossistema Gatsby se deteriora ainda mais.

Para uma avaliação detalhada do que uma migração pode custar para sua situação específica, confira nossa página de preços ou entre em contato.

Caminho de Migração: Gatsby para Next.js

Fiz isso o suficiente para ter um processo repetível. Aqui está a abordagem de alto nível:

Fase 1: Auditoria (1-2 semanas)

  • Inventariar todos os plugins Gatsby e seus equivalentes Next.js
  • Mapear a camada de dados GraphQL para chamadas de API diretas ou uso de SDK
  • Identificar lógica gatsby-node.js (criação de página, customização de schema)
  • Catalogar toda a funcionalidade dinâmica (busca, formulários, autenticação)

Fase 2: Fundação (1-2 semanas)

  • Configurar projeto Next.js com App Router
  • Configurar TypeScript, ESLint, Tailwind (ou sua abordagem CSS)
  • Configurar integração CMS diretamente (sem plugins source necessários)
  • Implementar estratégia de otimização de imagem usando next/image

Fase 3: Migração de Página (2-6 semanas, dependendo do tamanho)

  • Converter templates de página para componentes de página Next.js
  • Substituir gatsby-image / gatsby-plugin-image com next/image
  • Substituir <Link> do Gatsby com <Link> do Next.js (API similar, felizmente)
  • Migrar lógica gatsby-node.js createPages para generateStaticParams
  • Converter qualquer lógica gatsby-browser.js / gatsby-ssr.js para componentes de layout

Fase 4: Otimização (1-2 semanas)

  • Implementar ISR onde apropriado
  • Adicionar Server Components para seções com muitos dados
  • Configurar webhooks de revalidação sob demanda de seu CMS
  • Testes de performance e otimização
// Padrão comum de migração: Gatsby page query → Next.js data fetching

// ANTES (Gatsby)
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// DEPOIS (Next.js App Router)
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR: revalidar a cada hora

O maior gotcha em migração é o tratamento de imagem. O pipeline de imagem do Gatsby foi genuinamente excelente — o placeholder com blur-up, srcsets responsivos, lazy loading. A boa notícia é que next/image lida com tudo isso agora, mas a API é diferente e você vai precisar atualizar cada referência de imagem.

Quando Next.js Não é a Resposta

Quero ser justo aqui. Next.js não é a escolha certa para cada projeto.

Se você precisa de simplicidade absoluta para um blog ou site de docs, considere Astro. Astro envia zero JavaScript por padrão e tem excelente suporte para content collections. Para sites puramente orientados a conteúdo onde você não precisa da interatividade do React, Astro oferecerá melhor performance com menos complexidade.

Se você está construindo um site estático simples sem features dinâmicas, até 11ty ou Hugo podem servir melhor. Não traga um framework para uma briga de markup.

Se você está trancado no ecossistema Vue ou Svelte, Nuxt e SvelteKit são alternativas fortes em seus respectivos ecossistemas.

Mas se você precisa de React, precisa de um mix de conteúdo estático e dinâmico, precisa de ótima performance, e precisa de um framework que será ativamente mantido por anos — Next.js é a escolha óbvia em 2026.

O Veredicto

Next.js vence. Não está nem perto, e não esteve perto desde 2022.

Gatsby pioneirou ideias importantes no ecossistema React: otimização em tempo de construção, pipelines de processamento de imagem, o conceito de uma camada de dados unificada. Essas ideias vivem em diferentes formas em frameworks modernos. Mas como um framework de produção em 2026, Gatsby é uma responsabilidade.

Os argumentos técnicos são esmagadores:

  • RSC e o App Router oferecem uma vantagem arquitetural que Gatsby não pode igualar
  • Os tamanhos de bundle são 40-60% menores
  • Os scores de Core Web Vitals são consistentemente melhores
  • ISR e PPR oferecem flexibilidade de renderização que Gatsby nunca alcançou
  • O ecossistema está florescendo vs. estagnado

Os argumentos de negócio são igualmente claros:

  • Menor custo total de propriedade
  • Pool de talentos maior
  • Desenvolvimento ativo e suporte da Vercel
  • Caminhos claros de upgrade para o futuro próximo

Se você está iniciando um novo projeto, use Next.js (ou Astro se você não precisar de React). Se você está rodando Gatsby em produção, comece a planejar sua migração agora. Quanto mais você espera, mais difícil e caro fica.

Precisa de ajuda com essa migração? Nosso time fez muitas vezes. Vamos conversar.

— Aaron Mitchell, Senior Headless Engineer na Social Animal

FAQ

Gatsby está completamente morto em 2026?

Gatsby não foi oficialmente declarado fim de vida pela Netlify, mas está efetivamente em estado de manutenção apenas. Não houve nenhum release significativo desde v5.13 no final de 2023, o core team se dispersou, e o ecossistema de plugins está se deteriorando. Para novos projetos, não é uma escolha viável. Para projetos existentes, você deve estar planejando uma migração.

Quanto tempo leva para migrar do Gatsby para Next.js?

Para um site típico de marketing com 50-200 páginas, espere 4-8 semanas de tempo de desenvolvimento. Sites maiores com relacionamentos de dados complexos, plugins customizados, ou uso pesado de GraphQL podem levar 8-16 semanas. As maiores variáveis são o número de plugins Gatsby customizados que você está usando e quão profundamente você integrou com a camada de dados GraphQL do Gatsby.

Next.js é mais difícil de aprender que Gatsby?

O App Router e Server Components têm uma curva de aprendizado, especialmente se você vem do modelo baseado em páginas do Gatsby. No entanto, o modelo mental é ultimamente mais simples — você busca dados diretamente em vez de passar por uma camada GraphQL, e você escreve componentes que rodam no servidor ou no cliente. A maioria dos desenvolvedores encontra Next.js mais intuitivo uma vez que passam pelos conceitos iniciais de RSC.

Posso deployar Next.js sem Vercel?

Absolutamente. Next.js pode ser deployado em AWS (usando SST, Amplify, ou uma configuração customizada), Cloudflare Pages, DigitalOcean, Railway, Fly.io, ou self-hosted em qualquer servidor Node.js. Vercel oferece a experiência mais otimizada, mas você não está preso. O comando next start roda um servidor Node.js padrão.

E Astro vs Next.js para sites estáticos?

Para sites puramente orientados a conteúdo (blogs, documentação, páginas de marketing com interatividade mínima), Astro é frequentemente uma escolha melhor. Envia zero JavaScript por padrão e suporta múltiplos frameworks de UI. Se você precisa da interatividade do React, roteamento dinâmico, endpoints de API, autenticação, ou um mix de conteúdo estático e dinâmico, Next.js é o melhor ajuste. Trabalhamos com ambos — confira nossa página de desenvolvimento Astro para mais sobre quando recomendamos.

Quanto custa migrar do Gatsby para Next.js?

Os custos de desenvolvimento típicamente variam de $15.000 para um site simples de marketing até $50.000+ para aplicações complexas com pipelines de dados customizados, integração de e-commerce, ou internacionalização. O custo depende fortemente do número de plugins Gatsby que precisam ser substituídos, da complexidade de suas queries GraphQL, e se você quer modernizar a arquitetura (adicionando ISR, Server Components) durante a migração.

Next.js suporta exportação estática como Gatsby?

Sim. Rodando next build com output: 'export' em seu next.config.js gera um site completamente estático que pode ser hosteado em qualquer lugar — S3, GitHub Pages, qualquer CDN. Você perde ISR e features do lado do servidor, mas obtém o mesmo modelo de deployment do Gatsby. A maioria dos times descobre que não quer puro estático uma vez que experimentam os benefícios de ISR e Server Components, no entanto.

O que aconteceu com Gatsby Cloud?

Gatsby Cloud foi encerrado em Q1 2024, aproximadamente um ano após a aquisição da Netlify. Os usuários foram migrados para o hosting padrão da Netlify. Este foi um golpe significativo porque Gatsby Cloud fornecia builds otimizados, builds incrementais, e funcionalidade de preview que eram fortemente acopladas com a arquitetura do Gatsby. Sem Gatsby Cloud, os tempos de build em plataformas de CI/CD padrão são notavelmente piores.