I've been building production sites with both Next.js and Gatsby since 2019. I watched Gatsby raise $46 million, get acquired by Netlify, and then get quietly abandoned. I migrated three enterprise Gatsby sites to Next.js in 2025 alone. This isn't a theoretical comparison — it's a post-mortem on one framework and a honest assessment of the other.

If you're still running Gatsby in production, you need a migration plan. If you're choosing a framework for a new project, the answer is straightforward but nuanced. Let me walk you through all of it.

Table of Contents

Next.js vs Gatsby in 2026: The Complete Production Decision Guide

The State of Gatsby in 2026

Let's not sugarcoat this. Gatsby is, for all practical purposes, abandoned.

Netlify acquired Gatsby Inc. in February 2023. The promise was continued development and integration with Netlify's platform. What actually happened was a slow wind-down. The last meaningful Gatsby release (v5.13) shipped in late 2023. The GitHub repository has had minimal maintenance commits since mid-2024. Key maintainers left. The plugin ecosystem has stagnated — many popular plugins haven't been updated in over 18 months.

Here's the timeline that matters:

Date Event
Feb 2023 Netlify acquires Gatsby Inc.
Q3 2023 Gatsby v5.13 released (last significant release)
Q1 2024 Gatsby Cloud officially shut down
Q2 2024 Core team members depart Netlify
Q4 2024 npm weekly downloads drop below 150k (from 800k+ peak)
Q1 2025 Netlify removes Gatsby-specific docs from primary navigation
2026 No v6 release, no roadmap, effectively in maintenance mode

The npm download numbers tell the story. At its peak in 2021, Gatsby was pulling over 800,000 weekly downloads. As of early 2026, it's hovering around 100,000 — and most of those are existing CI/CD pipelines, not new projects.

I don't say this to dunk on Gatsby. It genuinely pushed the React ecosystem forward. The idea of a build-time data layer with GraphQL, image optimization at build time, the plugin architecture — these were real innovations. But the framework lost the technical argument when Next.js shipped ISR in late 2020, and it lost the business argument when Netlify stopped investing in it.

If you're running Gatsby in production right now, your biggest risks are:

  • Security vulnerabilities in unmaintained dependencies
  • Node.js version incompatibilities as the ecosystem moves forward
  • Plugin rot — third-party plugins breaking with no upstream fixes
  • Hiring difficulty — developers don't want Gatsby on their resume in 2026

Next.js in 2026: What's Actually Changed

Next.js 15 landed in late 2024, and the iterative releases through 2025 have solidified the App Router as the primary development model. Here's where things stand:

React Server Components (RSC) are now the default. When you create a component in the App Router, it's a Server Component unless you explicitly add 'use client'. This wasn't just a syntax change — it fundamentally altered how we think about data fetching and component architecture.

Partial Prerendering (PPR) hit stable in Next.js 15.1. This is the feature that would have killed Gatsby even if Gatsby were still actively developed. PPR lets you serve a static shell instantly while streaming dynamic content. You get the speed of SSG with the flexibility of SSR. It's the best of both worlds, and it's something Gatsby's architecture could never support.

Server Actions have matured significantly. Form handling, mutations, revalidation — the patterns are well-established now and they've replaced a lot of the API route boilerplate we used to write.

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

The Turbopack bundler is now the default for development (and stable for production builds as of early 2026). Cold start times for next dev dropped by 50-70% compared to webpack. Production builds are faster too, though the improvement there is more modest — around 20-30%.

Performance Benchmarks: Lighthouse, Bundle Size, Core Web Vitals

I ran benchmarks on equivalent sites — a marketing site with 50 pages, blog with 200 posts, image-heavy portfolio section. Same content, same hosting (Vercel for Next.js, Netlify for Gatsby). Here are the results from January 2026:

Lighthouse Scores (Mobile, Median of 5 Runs)

Metric 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 (seconds) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

Bundle Size Comparison

This is where things get really interesting. Gatsby ships a client-side runtime that includes React, the Gatsby runtime, and the data layer. Next.js with the App Router and RSC ships significantly less JavaScript to the client because Server Components don't contribute to the client bundle at all.

Metric Next.js 15 (App Router) Gatsby 5.13
First Load JS 87 KB (gzipped) 210 KB (gzipped)
Route JS (avg) 12 KB 45 KB
Total JS (50-page site) 145 KB 380 KB
Image optimization Built-in (on-demand) Build-time (gatsby-plugin-image)
Font optimization Built-in (next/font) Manual or plugin

The bundle size difference is largely thanks to RSC. In a typical Gatsby site, every component ships to the client even if it only renders static content. In Next.js with Server Components, a component that fetches data and renders HTML never hits the client bundle. That's a massive win.

Core Web Vitals in the Field

Lab benchmarks are useful, but field data matters more. Based on CrUX (Chrome User Experience Report) data from sites I've worked on:

  • Next.js sites: 85% pass all three Core Web Vitals thresholds
  • Gatsby sites: 62% pass all three (primarily failing on INP and TBT)

The INP (Interaction to Next Paint) metric is where Gatsby really struggles. The larger client-side JavaScript bundle means more main thread work, which means slower interactions. Gatsby's hydration model requires processing the entire page's data on the client, while Next.js with RSC avoids this entirely for server-rendered content.

Next.js vs Gatsby in 2026: The Complete Production Decision Guide - architecture

Architecture Comparison: RSC, App Router, SSG, ISR

Rendering Strategies

Gatsby was built around one rendering strategy: Static Site Generation (SSG). Everything gets built at build time. Gatsby added DSG (Deferred Static Generation) in v4, which was their answer to Next.js ISR, but it required Gatsby Cloud and was never as flexible.

Next.js gives you everything:

// Static Generation (equivalent to Gatsby's default)
// 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 - revalidate every 60 seconds
export const revalidate = 60

// Or on-demand revalidation 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 })
}

The Data Layer Problem

Gatsby's GraphQL data layer was innovative but ultimately became a liability. Every data source needed a source plugin. If the plugin didn't exist or wasn't maintained, you were stuck writing one yourself. The build-time GraphQL schema was powerful but added significant complexity and build time.

Next.js takes a different approach: just fetch data. Use whatever you want — REST APIs, GraphQL clients, database queries, CMS SDKs. There's no framework-imposed data layer. This is both simpler and more flexible.

// Next.js - fetch from any source, any way you want
async function getProducts() {
  // Direct database query
  const products = await prisma.product.findMany()
  
  // Or REST API
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // Or headless CMS SDK
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

For teams using headless CMS setups — Contentful, Sanity, Storyblok, whatever — Next.js is dramatically easier to integrate. You don't need a source plugin. You just call the API. We cover this in depth in our headless CMS development work.

Server Components Change Everything

I keep coming back to RSC because it's genuinely the most important architectural shift in React since hooks. Here's why it matters for this comparison:

In Gatsby, your entire page component tree ships to the client. Even if a component just renders a list of blog post titles fetched from a CMS, that component's code and its data get serialized and sent to the browser for hydration.

In Next.js with RSC, that same component runs on the server, renders HTML, and the client never sees the component code or the raw data. The browser gets HTML. That's it.

This means:

  • Smaller bundles (as shown above)
  • No hydration mismatch bugs for server-only components
  • You can use server-only code (database queries, file system access) directly in components
  • Sensitive data (API keys, business logic) stays on the server

Developer Experience and Ecosystem

Aspect Next.js 15 Gatsby 5
TypeScript support First-class, auto-generated types Decent, but some plugin types missing
Hot reload speed ~200ms (Turbopack) 1-3 seconds (webpack)
Build time (200 pages) ~45 seconds ~3-5 minutes
Plugin ecosystem npm packages (universal) Gatsby-specific plugins (stagnant)
Documentation Actively maintained Mostly frozen since 2023
Community (Discord/GitHub) Very active Near-silent
Job market demand High Declining rapidly
Learning resources (2025-2026) Abundant Scarce

The developer experience gap has widened dramatically. Next.js with Turbopack gives you near-instant hot reloads. Gatsby's webpack-based dev server feels sluggish by comparison, especially on larger sites.

Build times deserve special mention. A 500-page Gatsby site with heavy image processing could take 15-20 minutes to build. The equivalent Next.js site with on-demand image optimization builds in under 2 minutes because images are processed at request time (and then cached), not at build time.

Our Next.js development team has seen this play out across dozens of projects. Build times directly impact developer productivity and CI/CD costs.

Total Cost of Ownership

Let's talk money. This is where the decision gets real for business stakeholders.

Hosting Costs

Scenario Next.js on Vercel Gatsby on Netlify
Small site (< 100 pages, low traffic) $0-20/mo $0-19/mo
Medium site (500 pages, 100k visits/mo) $20-150/mo $19-99/mo
Large site (5000+ pages, 1M+ visits/mo) $150-500/mo $99-300/mo*

*Gatsby hosting costs are lower because it's pure static — no server compute. But you pay in build times and build minutes.

Next.js can also be deployed to other platforms: AWS (via SST or Amplify), Cloudflare, self-hosted with Node.js. Gatsby's pure static output gives it more hosting flexibility in theory, but in practice you lose ISR and any dynamic features.

Development Costs

This is where the real cost difference lives:

  • Gatsby developer rates: $120-180/hr (scarce, premium for legacy knowledge)
  • Next.js developer rates: $100-200/hr (wider range due to larger talent pool)
  • Migration cost (medium Gatsby site → Next.js): $15,000-50,000 depending on complexity
  • Ongoing maintenance (Gatsby): Higher due to dependency management, plugin fixes
  • Ongoing maintenance (Next.js): Lower, more straightforward upgrade paths

The hidden cost of staying on Gatsby is technical debt accruing daily. Every month you wait, the migration becomes slightly harder as the Gatsby ecosystem deteriorates further.

For a detailed assessment of what a migration might cost for your specific situation, check our pricing page or get in touch.

Migration Path: Gatsby to Next.js

I've done this enough times to have a repeatable process. Here's the high-level approach:

Phase 1: Audit (1-2 weeks)

  • Inventory all Gatsby plugins and their Next.js equivalents
  • Map the GraphQL data layer to direct API calls or SDK usage
  • Identify gatsby-node.js logic (page creation, schema customization)
  • Catalog all dynamic functionality (search, forms, auth)

Phase 2: Foundation (1-2 weeks)

  • Set up Next.js project with App Router
  • Configure TypeScript, ESLint, Tailwind (or your CSS approach)
  • Set up the CMS integration directly (no source plugins needed)
  • Implement the image optimization strategy using next/image

Phase 3: Page Migration (2-6 weeks, depending on size)

  • Convert page templates to Next.js page components
  • Replace gatsby-image / gatsby-plugin-image with next/image
  • Replace <Link> from Gatsby with <Link> from Next.js (similar API, thankfully)
  • Migrate gatsby-node.js createPages logic to generateStaticParams
  • Convert any gatsby-browser.js / gatsby-ssr.js logic to layout components

Phase 4: Optimization (1-2 weeks)

  • Implement ISR where appropriate
  • Add Server Components for data-heavy sections
  • Set up on-demand revalidation webhooks from your CMS
  • Performance testing and optimization
// Common migration pattern: Gatsby page query → Next.js data fetching

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

// AFTER (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: revalidate hourly

The biggest gotcha in migration is the image handling. Gatsby's image pipeline was genuinely excellent — the blur-up placeholder, responsive srcsets, lazy loading. The good news is next/image handles all of this now, but the API is different and you'll need to update every image reference.

When Next.js Isn't the Answer

I want to be fair here. Next.js isn't the right choice for every project.

If you need absolute simplicity for a blog or docs site, consider Astro. Astro ships zero JavaScript by default and has excellent content collection support. For purely content-driven sites where you don't need React's interactivity, Astro will give you better performance with less complexity.

If you're building a simple static site with no dynamic features, even 11ty or Hugo might serve you better. Don't bring a framework to a markup fight.

If you're locked into the Vue or Svelte ecosystem, Nuxt and SvelteKit are strong alternatives in their respective ecosystems.

But if you need React, need a mix of static and dynamic content, need great performance, and need a framework that will be actively maintained for years to come — Next.js is the obvious choice in 2026.

The Verdict

Next.js wins. It's not even close, and it hasn't been close since 2022.

Gatsby pioneered important ideas in the React ecosystem: build-time optimization, image processing pipelines, the concept of a unified data layer. These ideas live on in different forms across modern frameworks. But as a production framework in 2026, Gatsby is a liability.

The technical arguments are overwhelming:

  • RSC and the App Router give Next.js an architectural advantage Gatsby can't match
  • Bundle sizes are 40-60% smaller
  • Core Web Vitals scores are consistently better
  • ISR and PPR provide rendering flexibility Gatsby never achieved
  • The ecosystem is thriving vs. stagnating

The business arguments are equally clear:

  • Lower total cost of ownership
  • Larger talent pool
  • Active development and support from Vercel
  • Clear upgrade paths for the foreseeable future

If you're starting a new project, use Next.js (or Astro if you don't need React). If you're running Gatsby in production, start planning your migration now. The longer you wait, the harder and more expensive it gets.

Need help with that migration? Our team has done it many times. Let's talk.

— Aaron Mitchell, Senior Headless Engineer at Social Animal

FAQ

Is Gatsby completely dead in 2026? Gatsby hasn't been officially declared end-of-life by Netlify, but it's effectively in a maintenance-only state. There's been no significant release since v5.13 in late 2023, the core team has dispersed, and the plugin ecosystem is deteriorating. For new projects, it's not a viable choice. For existing projects, you should be planning a migration.

How long does it take to migrate from Gatsby to Next.js? For a typical marketing site with 50-200 pages, expect 4-8 weeks of development time. Larger sites with complex data relationships, custom plugins, or heavy GraphQL usage can take 8-16 weeks. The biggest variables are the number of custom Gatsby plugins you're using and how deeply you've integrated with Gatsby's GraphQL data layer.

Is Next.js harder to learn than Gatsby? The App Router and Server Components do have a learning curve, especially if you're coming from Gatsby's pages-based model. However, the mental model is ultimately simpler — you fetch data directly instead of going through a GraphQL layer, and you write components that run either on the server or client. Most developers find Next.js more intuitive once they get past the initial RSC concepts.

Can I deploy Next.js without Vercel? Absolutely. Next.js can be deployed to AWS (using SST, Amplify, or a custom setup), Cloudflare Pages, DigitalOcean, Railway, Fly.io, or self-hosted on any Node.js server. Vercel provides the most optimized experience, but you're not locked in. The next start command runs a standard Node.js server.

What about Astro vs Next.js for static sites? For purely content-driven sites (blogs, documentation, marketing pages with minimal interactivity), Astro is often a better choice. It ships zero JavaScript by default and supports multiple UI frameworks. If you need React's interactivity, dynamic routing, API endpoints, authentication, or a mix of static and dynamic content, Next.js is the better fit. We work with both — check our Astro development page for more on when we recommend it.

How much does it cost to migrate from Gatsby to Next.js? Development costs typically range from $15,000 for a simple marketing site to $50,000+ for complex applications with custom data pipelines, e-commerce integration, or internationalization. The cost depends heavily on the number of Gatsby plugins that need replacement, the complexity of your GraphQL queries, and whether you want to modernize the architecture (adding ISR, Server Components) during the migration.

Does Next.js support static export like Gatsby? Yes. Running next build with output: 'export' in your next.config.js generates a fully static site that can be hosted anywhere — S3, GitHub Pages, any CDN. You lose ISR and server-side features, but you get the same deployment model as Gatsby. Most teams find they don't want pure static once they experience the benefits of ISR and Server Components, though.

What happened to Gatsby Cloud? Gatsby Cloud was shut down in Q1 2024, roughly a year after Netlify's acquisition. Users were migrated to Netlify's standard hosting. This was a significant blow because Gatsby Cloud provided optimized builds, incremental builds, and preview functionality that were tightly coupled with Gatsby's architecture. Without Gatsby Cloud, build times on standard CI/CD platforms are noticeably worse.