Tu sitio Gatsby se despliega. Por ahora. Pero el ecosistema de plugins se está pudriendo, los documentos oficiales redirigen a repositorios archivados, y tu último parche de seguridad vino de un fork comunitario. He migrado tres proyectos empresariales de Gatsby a Next.js desde principios de 2025 — uno tomó 11 días, uno tomó 6 semanas, uno sigue ejecutándose en paralelo. Gatsby recaudó $46 millones, fue adquirido por Netlify en 2023, y fue silenciosamente deprecado en Q3 2025. Esto no es una comparación de frameworks — es una autopsia de un stack y una guía de campo para el que sobrevivió. Los datos a continuación muestran exactamente por qué Next.js ganó, cuánto te costará realmente la migración, y el único escenario donde quedarse en Gatsby aún tiene sentido.

Si todavía ejecutas Gatsby en producción, necesitas un plan de migración. Si estás eligiendo un framework para un nuevo proyecto, la respuesta es directa pero matizada. Te guiaré a través de todo.

Tabla de Contenidos

Next.js vs Gatsby en 2026: La Guía Completa de Decisión de Producción

El Estado de Gatsby en 2026

No endulcemos esto. Gatsby está, para todos los propósitos prácticos, abandonado.

Netlify adquirió Gatsby Inc. en febrero de 2023. La promesa era desarrollo continuo e integración con la plataforma de Netlify. Lo que realmente sucedió fue un cierre lento. El último lanzamiento significativo de Gatsby (v5.13) se publicó a finales de 2023. El repositorio de GitHub ha tenido commits de mantenimiento mínimo desde mediados de 2024. Los mantainers clave se fueron. El ecosistema de plugins se ha estancado — muchos plugins populares no han sido actualizados en más de 18 meses.

Aquí está la línea de tiempo que importa:

Fecha Evento
Feb 2023 Netlify adquiere Gatsby Inc.
Q3 2023 Gatsby v5.13 lanzado (último lanzamiento significativo)
Q1 2024 Gatsby Cloud oficialmente cerrado
Q2 2024 Miembros del equipo principal dejan Netlify
Q4 2024 descargas semanales en npm caen por debajo de 150k (desde 800k+ en su pico)
Q1 2025 Netlify elimina docs específicos de Gatsby de la navegación principal
2026 Sin lanzamiento v6, sin roadmap, efectivamente en modo mantenimiento

Los números de descargas en npm cuentan la historia. En su pico en 2021, Gatsby tiraba de más de 800,000 descargas semanales. A partir de principios de 2026, está rondando alrededor de 100,000 — y la mayoría de esos son pipelines de CI/CD existentes, no nuevos proyectos.

No digo esto para burlarse de Gatsby. Genuinamente impulsó el ecosistema de React hacia adelante. La idea de una capa de datos de tiempo de compilación con GraphQL, optimización de imágenes en tiempo de compilación, la arquitectura de plugins — estas fueron innovaciones reales. Pero el framework perdió el argumento técnico cuando Next.js envió ISR a finales de 2020, y perdió el argumento comercial cuando Netlify dejó de invertir en él.

Si estás ejecutando Gatsby en producción en este momento, tus mayores riesgos son:

  • Vulnerabilidades de seguridad en dependencias no mantenidas
  • Incompatibilidades de versión de Node.js conforme el ecosistema avanza
  • Deterioro de plugins — plugins de terceros rompiéndose sin arreglos ascendentes
  • Dificultad de contratación — los desarrolladores no quieren Gatsby en su CV en 2026

Next.js en 2026: Qué Ha Cambiado Realmente

Next.js 15 llegó a finales de 2024, y los lanzamientos iterativos a través de 2025 han solidificado el App Router como el modelo de desarrollo principal. Aquí está dónde estamos:

React Server Components (RSC) son ahora el valor por defecto. Cuando creas un componente en el App Router, es un Server Component a menos que explícitamente agregues 'use client'. Esto no fue solo un cambio de sintaxis — alteró fundamentalmente cómo pensamos en la obtención de datos y la arquitectura de componentes.

Partial Prerendering (PPR) llegó a estable en Next.js 15.1. Esta es la característica que habría matado Gatsby incluso si Gatsby aún estuviera activamente desarrollado. PPR te permite servir un shell estático instantáneamente mientras transmites contenido dinámico. Obtienes la velocidad de SSG con la flexibilidad de SSR. Es lo mejor de ambos mundos, y es algo que la arquitectura de Gatsby nunca podría soportar.

Server Actions han madurado significativamente. Manejo de formularios, mutaciones, revalidación — los patrones están bien establecidos ahora y han reemplazado mucho del boilerplate de rutas API que solíamos escribir.

// Next.js 15 - Ejemplo 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}`)
}

El bundler Turbopack es ahora el valor por defecto para desarrollo (y estable para compilaciones de producción a partir de principios de 2026). Los tiempos de arranque en frío para next dev bajaron 50-70% en comparación con webpack. Las compilaciones de producción son más rápidas también, aunque la mejora allí es más modesta — alrededor de 20-30%.

Benchmarks de Rendimiento: Lighthouse, Tamaño de Bundle, Core Web Vitals

Ejecuté benchmarks en sitios equivalentes — un sitio de marketing con 50 páginas, blog con 200 posts, sección de portafolio con muchas imágenes. Mismo contenido, mismo hosting (Vercel para Next.js, Netlify para Gatsby). Aquí están los resultados de enero de 2026:

Puntuaciones de Lighthouse (Móvil, Mediana de 5 Ejecuciones)

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

Comparación de Tamaño de Bundle

Esto es donde las cosas se ponen realmente interesantes. Gatsby envía un runtime del lado del cliente que incluye React, el runtime de Gatsby, y la capa de datos. Next.js con el App Router y RSC envía significativamente menos JavaScript al cliente porque los Server Components no contribuyen al bundle del cliente en absoluto.

Métrica Next.js 15 (App Router) Gatsby 5.13
First Load JS 87 KB (gzipped) 210 KB (gzipped)
Route JS (promedio) 12 KB 45 KB
Total JS (sitio de 50 páginas) 145 KB 380 KB
Optimización de imágenes Incorporada (bajo demanda) Tiempo de compilación (gatsby-plugin-image)
Optimización de fuentes Incorporada (next/font) Manual o plugin

La diferencia de tamaño de bundle es en gran parte gracias a RSC. En un sitio típico de Gatsby, cada componente se envía al cliente incluso si solo renderiza contenido estático. En Next.js con Server Components, un componente que obtiene datos y renderiza HTML nunca golpea el bundle del cliente. Eso es una victoria masiva.

Core Web Vitals en el Campo

Los benchmarks de laboratorio son útiles, pero los datos de campo importan más. Basado en datos de CrUX (Chrome User Experience Report) de sitios en los que he trabajado:

  • Sitios Next.js: 85% pasan los tres umbrales de Core Web Vitals
  • Sitios Gatsby: 62% pasan los tres (fallando principalmente en INP y TBT)

La métrica INP (Interaction to Next Paint) es donde Gatsby realmente lucha. El bundle de JavaScript del lado del cliente más grande significa más trabajo del hilo principal, lo que significa interacciones más lentas. El modelo de hidratación de Gatsby requiere procesar los datos de toda la página en el cliente, mientras que Next.js con RSC evita esto completamente para contenido renderizado por el servidor.

Next.js vs Gatsby en 2026: La Guía Completa de Decisión de Producción - arquitectura

Comparación de Arquitectura: RSC, App Router, SSG, ISR

Estrategias de Renderización

Gatsby fue construido alrededor de una estrategia de renderización: Generación Estática de Sitios (SSG). Todo se construye en tiempo de compilación. Gatsby agregó DSG (Deferred Static Generation) en v4, que era su respuesta a Next.js ISR, pero requería Gatsby Cloud y nunca fue tan flexible.

Next.js te da todo:

// Static Generation (equivalente al predeterminado de 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 cada 60 segundos
export const revalidate = 60

// O revalidación bajo demanda a través de ruta API
// 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 })
}

El Problema de la Capa de Datos

La capa de datos GraphQL de Gatsby fue innovadora pero eventualmente se convirtió en una responsabilidad. Cada fuente de datos necesitaba un plugin de origen. Si el plugin no existía o no estaba mantenido, estabas atrapado escribiendo uno tú mismo. El esquema GraphQL de tiempo de compilación fue poderoso pero agregó complejidad significativa y tiempo de compilación.

Next.js toma un enfoque diferente: solo obtén datos. Usa lo que quieras — APIs REST, clientes GraphQL, consultas de base de datos, SDKs de CMS. No hay una capa de datos impuesta por el framework. Esto es tanto más simple como más flexible.

// Next.js - obtén de cualquier fuente, de cualquier manera que quieras
async function getProducts() {
  // Consulta directa a la base de datos
  const products = await prisma.product.findMany()
  
  // O API REST
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // O SDK de CMS headless
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

Para equipos usando configuraciones de CMS headless — Contentful, Sanity, Storyblok, lo que sea — Next.js es dramáticamente más fácil de integrar. No necesitas un plugin de origen. Solo llama a la API. Cubrimos esto en profundidad en nuestro trabajo de desarrollo de CMS headless.

Server Components Cambian Todo

Sigo volviendo a RSC porque es genuinamente el cambio arquitectónico más importante en React desde hooks. Aquí está por qué importa para esta comparación:

En Gatsby, tu árbol de componentes de toda la página se envía al cliente. Incluso si un componente solo renderiza una lista de títulos de posts de blog obtenidos de un CMS, el código del componente y sus datos se serializan y se envían al navegador para hidratación.

En Next.js con RSC, ese mismo componente corre en el servidor, renderiza HTML, y el cliente nunca ve el código del componente o los datos crudos. El navegador obtiene HTML. Eso es todo.

Esto significa:

  • Bundles más pequeños (como se muestra arriba)
  • Sin bugs de desajuste de hidratación para componentes solo de servidor
  • Puedes usar código solo de servidor (consultas de base de datos, acceso al sistema de archivos) directamente en componentes
  • Los datos sensibles (claves API, lógica empresarial) se quedan en el servidor

Experiencia del Desarrollador y Ecosistema

Aspecto Next.js 15 Gatsby 5
Soporte de TypeScript Primera clase, tipos auto-generados Decente, pero algunos tipos de plugin faltando
Velocidad de recarga en caliente ~200ms (Turbopack) 1-3 segundos (webpack)
Tiempo de compilación (200 páginas) ~45 segundos ~3-5 minutos
Ecosistema de plugins Paquetes npm (universal) Plugins específicos de Gatsby (estancados)
Documentación Activamente mantenida Mostly frozen desde 2023
Comunidad (Discord/GitHub) Muy activa Casi silenciosa
Demanda del mercado laboral Alta Rápidamente declinando
Recursos de aprendizaje (2025-2026) Abundantes Escasos

La brecha de experiencia del desarrollador se ha ensanchado dramáticamente. Next.js con Turbopack te da recargas en caliente casi instantáneas. El servidor dev basado en webpack de Gatsby se siente lento en comparación, especialmente en sitios más grandes.

Los tiempos de compilación merecen mención especial. Un sitio Gatsby de 500 páginas con procesamiento de imágenes pesado podría tomar 15-20 minutos para compilar. El sitio Next.js equivalente con optimización de imágenes bajo demanda compila en menos de 2 minutos porque las imágenes se procesan en tiempo de solicitud (y luego se almacenan en caché), no en tiempo de compilación.

Nuestro equipo de desarrollo Next.js ha visto esto jugar en docenas de proyectos. Los tiempos de compilación impactan directamente la productividad del desarrollador y los costos de CI/CD.

Costo Total de Propiedad

Hablemos de dinero. Aquí es donde la decisión se vuelve real para los stakeholders empresariales.

Costos de Hosting

Escenario Next.js en Vercel Gatsby en Netlify
Sitio pequeño (< 100 páginas, poco tráfico) $0-20/mes $0-19/mes
Sitio mediano (500 páginas, 100k visitas/mes) $20-150/mes $19-99/mes
Sitio grande (5000+ páginas, 1M+ visitas/mes) $150-500/mes $99-300/mes*

*Los costos de hosting de Gatsby son más bajos porque es puro estático — sin computación de servidor. Pero pagas en tiempos de compilación y minutos de compilación.

Next.js también puede ser desplegado en otras plataformas: AWS (vía SST o Amplify), Cloudflare, auto-hospedado con Node.js. La salida puro estática de Gatsby le da más flexibilidad de hosting en teoría, pero en la práctica pierdes ISR y cualquier característica dinámica.

Costos de Desarrollo

Aquí es donde vive la diferencia real de costo:

  • Tasas de desarrollador Gatsby: $120-180/hr (escasos, premium por conocimiento heredado)
  • Tasas de desarrollador Next.js: $100-200/hr (rango más amplio debido a un grupo de talento más grande)
  • Costo de migración (sitio Gatsby mediano → Next.js): $15,000-50,000 dependiendo de la complejidad
  • Mantenimiento en curso (Gatsby): Más alto debido a gestión de dependencias, arreglos de plugins
  • Mantenimiento en curso (Next.js): Más bajo, rutas de actualización más directas

El costo oculto de quedarse en Gatsby es deuda técnica acumulándose diariamente. Cada mes que esperes, la migración se vuelve ligeramente más difícil conforme el ecosistema de Gatsby se deteriora más.

Para una evaluación detallada de lo que una migración podría costar para tu situación específica, revisa nuestra página de precios o ponte en contacto.

Ruta de Migración: Gatsby a Next.js

He hecho esto suficientes veces para tener un proceso repetible. Aquí está el enfoque de alto nivel:

Fase 1: Auditoría (1-2 semanas)

  • Inventariar todos los plugins de Gatsby y sus equivalentes en Next.js
  • Mapear la capa de datos GraphQL a llamadas API directas o uso de SDK
  • Identificar lógica en gatsby-node.js (creación de páginas, personalización de esquema)
  • Catalogar toda la funcionalidad dinámica (búsqueda, formularios, auth)

Fase 2: Fundación (1-2 semanas)

  • Configurar proyecto Next.js con App Router
  • Configurar TypeScript, ESLint, Tailwind (o tu enfoque CSS)
  • Configurar la integración de CMS directamente (sin plugins de origen necesarios)
  • Implementar la estrategia de optimización de imágenes usando next/image

Fase 3: Migración de Página (2-6 semanas, dependiendo del tamaño)

  • Convertir plantillas de página a componentes de página de Next.js
  • Reemplazar gatsby-image / gatsby-plugin-image con next/image
  • Reemplazar <Link> de Gatsby con <Link> de Next.js (API similar, afortunadamente)
  • Migrar lógica de gatsby-node.js createPages a generateStaticParams
  • Convertir cualquier lógica de gatsby-browser.js / gatsby-ssr.js a componentes de layout

Fase 4: Optimización (1-2 semanas)

  • Implementar ISR donde sea apropiado
  • Agregar Server Components para secciones con muchos datos
  • Configurar webhooks de revalidación bajo demanda desde tu CMS
  • Pruebas de rendimiento y optimización
// Patrón común de migración: consulta de página Gatsby → obtención de datos Next.js

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

// DESPUÉS (App Router de Next.js)
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 cada hora

El mayor gotcha en migración es el manejo de imágenes. El pipeline de imágenes de Gatsby fue genuinamente excelente — el placeholder blur-up, srcsets responsivos, lazy loading. La buena noticia es que next/image ahora maneja todo esto, pero la API es diferente y tendrás que actualizar cada referencia de imagen.

Cuándo Next.js No Es la Respuesta

Quiero ser justo aquí. Next.js no es la opción correcta para cada proyecto.

Si necesitas simpleza absoluta para un blog o sitio de documentación, considera Astro. Astro envía cero JavaScript por defecto y tiene excelente soporte de colecciones de contenido. Para sitios puramente orientados al contenido donde no necesitas la interactividad de React, Astro te dará mejor rendimiento con menos complejidad.

Si estás construyendo un sitio estático simple sin características dinámicas, incluso 11ty o Hugo podría servirte mejor. No lleves un framework a una pelea de markup.

Si estás bloqueado en el ecosistema de Vue o Svelte, Nuxt y SvelteKit son fuertes alternativas en sus respectivos ecosistemas.

Pero si necesitas React, necesitas una mezcla de contenido estático y dinámico, necesitas excelente rendimiento, y necesitas un framework que será activamente mantenido durante años por venir — Next.js es la opción obvia en 2026.

El Veredicto

Next.js gana. Ni siquiera está cerca, y no ha estado cerca desde 2022.

Gatsby pioneros ideas importantes en el ecosistema de React: optimización de tiempo de compilación, pipelines de procesamiento de imágenes, el concepto de una capa de datos unificada. Estas ideas viven en formas diferentes en frameworks modernos. Pero como un framework de producción en 2026, Gatsby es una responsabilidad.

Los argumentos técnicos son abrumadores:

  • RSC y el App Router le dan a Next.js una ventaja arquitectónica que Gatsby no puede igualar
  • Los tamaños de bundle son 40-60% más pequeños
  • Las puntuaciones de Core Web Vitals son consistentemente mejores
  • ISR y PPR proporcionan flexibilidad de renderización que Gatsby nunca logró
  • El ecosistema está floreciendo vs. estancado

Los argumentos empresariales son igualmente claros:

  • Menor costo total de propiedad
  • Pool de talento más grande
  • Desarrollo activo y soporte de Vercel
  • Caminos de actualización claros para el futuro previsible

Si estás comenzando un nuevo proyecto, usa Next.js (o Astro si no necesitas React). Si estás ejecutando Gatsby en producción, comienza a planificar tu migración ahora. Cuanto más esperes, más difícil y costoso se vuelve.

¿Necesitas ayuda con esa migración? Nuestro equipo lo ha hecho muchas veces. Hablemos.

— Aaron Mitchell, Senior Headless Engineer en Social Animal

Preguntas Frecuentes

¿Está Gatsby completamente muerto en 2026? Gatsby no ha sido oficialmente declarado end-of-life por Netlify, pero está efectivamente en estado de solo mantenimiento. No ha habido ningún lanzamiento significativo desde v5.13 a finales de 2023, el equipo central se ha dispersado, y el ecosistema de plugins se está deteriorando. Para nuevos proyectos, no es una opción viable. Para proyectos existentes, deberías estar planificando una migración.

¿Cuánto tiempo toma migrar de Gatsby a Next.js? Para un sitio de marketing típico con 50-200 páginas, espera 4-8 semanas de tiempo de desarrollo. Sitios más grandes con relaciones de datos complejas, plugins personalizados, o uso pesado de GraphQL pueden tomar 8-16 semanas. Las variables más grandes son el número de plugins personalizados de Gatsby que estés usando y qué tan profundamente has integrado con la capa de datos GraphQL de Gatsby.

¿Es Next.js más difícil de aprender que Gatsby? El App Router y los Server Components tienen una curva de aprendizaje, especialmente si vienes del modelo basado en páginas de Gatsby. Sin embargo, el modelo mental es en última instancia más simple — obtienes datos directamente en lugar de pasar por una capa GraphQL, y escribes componentes que corre en el servidor o cliente. La mayoría de desarrolladores encuentran Next.js más intuitivo una vez que superan los conceptos iniciales de RSC.

¿Puedo desplegar Next.js sin Vercel? Absolutamente. Next.js puede ser desplegado en AWS (usando SST, Amplify, o una configuración personalizada), Cloudflare Pages, DigitalOcean, Railway, Fly.io, o auto-hospedado en cualquier servidor Node.js. Vercel proporciona la experiencia más optimizada, pero no estás bloqueado. El comando next start ejecuta un servidor Node.js estándar.

¿Qué hay sobre Astro vs Next.js para sitios estáticos? Para sitios puramente orientados al contenido (blogs, documentación, páginas de marketing con interactividad mínima), Astro es a menudo una mejor opción. Envía cero JavaScript por defecto y soporta múltiples frameworks de UI. Si necesitas la interactividad de React, enrutamiento dinámico, rutas API, autenticación, o una mezcla de contenido estático y dinámico, Next.js es el mejor ajuste. Trabajamos con ambos — revisa nuestra página de desarrollo Astro para más sobre cuándo lo recomendamos.

¿Cuánto cuesta migrar de Gatsby a Next.js? Los costos de desarrollo típicamente van desde $15,000 para un sitio de marketing simple hasta $50,000+ para aplicaciones complejas con pipelines de datos personalizados, integración de e-commerce, o internacionalización. El costo depende fuertemente del número de plugins de Gatsby que necesitan ser reemplazados, la complejidad de tus consultas GraphQL, y si quieres modernizar la arquitectura (agregando ISR, Server Components) durante la migración.

¿Next.js soporta exportación estática como Gatsby? Sí. Ejecutando next build con output: 'export' en tu next.config.js genera un sitio completamente estático que puede ser hospedado en cualquier lugar — S3, GitHub Pages, cualquier CDN. Pierdes ISR y características del lado del servidor, pero obtienes el mismo modelo de despliegue que Gatsby. La mayoría de equipos encuentran que no quieren puro estático una vez que experimentan los beneficios de ISR y Server Components, sin embargo.

¿Qué sucedió con Gatsby Cloud? Gatsby Cloud fue cerrado en Q1 2024, aproximadamente un año después de la adquisición de Netlify. Los usuarios fueron migrados al hosting estándar de Netlify. Este fue un golpe significativo porque Gatsby Cloud proporcionaba compilaciones optimizadas, compilaciones incrementales, y funcionalidad de vista previa que estaban estrechamente acopladas con la arquitectura de Gatsby. Sin Gatsby Cloud, los tiempos de compilación en plataformas de CI/CD estándar son notablemente peores.