Next.js vs Gatsby in 2026: Why One Framework Died and What It Cost to Leave

Next.js has effectively replaced Gatsby for production React sites in 2026. Gatsby's development stalled after Netlify's 2023 acquisition. Meanwhile, Next.js added React Server Components, Partial Prerendering, and Turbopack. Moving off Gatsby usually costs weeks of developer time and a mid five-figure budget. But staying costs more in security risk and shrinking plugin support.

Key takeaways

• Gatsby has shipped no major release since v5.13 in late 2023. Netlify shut down Gatsby Cloud in Q1 2024, and its plugin ecosystem has since decayed.
• Next.js 15's React Server Components and Partial Prerendering cut client-side JavaScript. It generally scores better on Core Web Vitals than Gatsby's client-heavy hydration model.
• Typical Gatsby-to-Next.js migrations take 4 to 16 weeks. The time depends on plugin count and GraphQL complexity. Our own Next.js migration work, including the SleepDr.com rebuild, follows a similar phased process.
• Hosting costs for Next.js and Gatsby are often comparable. But developer availability and long-term maintenance tend to favor Next.js.
• For pure content sites with minimal interactivity, Astro is often a better fit than either framework.

Updated 15 August 2026: sources added, experience claims checked against our project record, summary added.

The State of Gatsby in 2026

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

Netlify bought Gatsby Inc. in February 2023. By then the company had raised roughly $46 million in venture funding. 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 few maintenance commits since mid-2024, and key maintainers left the project. The plugin ecosystem has stalled. Many popular plugins have gone without real updates for a long stretch.

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

Sources: Gatsby release notes, Gatsby on GitHub, Gatsby background on Wikipedia).

npm weekly download data tells the story. At its peak in 2021, Gatsby pulled over 800,000 weekly downloads. As of early 2026 that figure sits around 100,000. Most of those come from existing CI/CD pipelines, not new projects.

None of this dismisses Gatsby's contribution. It pushed the React ecosystem forward. A build-time data layer with GraphQL, image optimization at build time, and a real plugin architecture were all meaningful advances. But the framework lost the technical argument once Next.js shipped ISR in late 2020. 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. The iterative releases through 2025 made the App Router the main way to build. 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 add 'use client'. This wasn't just a syntax change. It changed how teams think about data fetching and component architecture.

Partial Prerendering (PPR) hit stable in Next.js 15.1. This feature would have kept Gatsby competitive even if it were still actively developed. PPR serves a static shell instantly while streaming dynamic content. It combines the speed of SSG with the flexibility of SSR in a way Gatsby's architecture could never support.

Server Actions have matured a lot. Form handling, mutations, and revalidation patterns are now well established. They've replaced much of the API route boilerplate developers 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}`)
}

Turbopack is now the default bundler for development, and stable for production builds as of early 2026. Cold start times for next dev have dropped a lot compared to webpack. Production builds are faster too, though the gain there is smaller.

Performance Benchmarks: Lighthouse, Bundle Size, Core Web Vitals

These ranges come from comparing equivalent Next.js App Router and Gatsby 5 builds on similar hosting (Vercel for Next.js, Netlify for Gatsby): a marketing site with 50 pages, a blog with 200 posts, and an image-heavy portfolio section. Treat these as typical patterns, not a single controlled study.

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 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 much less JavaScript to the client, because Server Components don't add 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

RSC drives most of this bundle size gap. 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 reaches the client bundle. That's a big win.

Core Web Vitals in the Field

Lab benchmarks are useful, but field data matters more. Chrome's CrUX report tracks real-world Core Web Vitals, and the pattern holds: production Next.js sites pass all three Core Web Vitals thresholds more often than equivalent Gatsby sites. This is mainly because Gatsby's client-heavy hydration model tends to fail INP and TBT thresholds more often.

The larger client-side JavaScript bundle in Gatsby means more main-thread work, which means slower interactions. Gatsby's hydration model needs to process the whole page's data on the client. Next.js with RSC skips this step entirely for server-rendered content.

Architecture Comparison: RSC, App Router, SSG, ISR

Rendering Strategies

Gatsby was built around one rendering strategy: Static Site Generation (SSG), where everything gets built at build time. Gatsby added DSG (Deferred Static Generation) in v4 as its answer to Next.js ISR. But it needed 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 inventive but became a liability. Every data source needed a source plugin. If the plugin didn't exist or wasn't maintained, you had to write one yourself. The build-time GraphQL schema was powerful, but it added real complexity and build time.

Next.js takes a different approach: just fetch data. Use whatever you want. REST APIs, GraphQL clients, database queries, or CMS SDKs all work. There's no framework-imposed data layer, which is 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 such as Contentful, Sanity, or Storyblok, Next.js is much 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

RSC is arguably the biggest architectural shift in React since hooks. Here's why it matters for this comparison.

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

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

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 grown wider. Next.js with Turbopack gives near-instant hot reloads. Gatsby's webpack-based dev server feels sluggish in 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 same Next.js site with on-demand image optimization builds in under 2 minutes. That's because images are processed at request time and cached, not at build time.

Our Next.js development team sees this build-time gap directly affect CI/CD costs and shipping speed for teams moving off Gatsby.

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, with no server compute. But you pay for that in build times and build minutes. Current tiers are published on Vercel's pricing page and Netlify's pricing page.

Next.js can also deploy to other platforms: AWS (via SST or Amplify), Cloudflare, or a self-hosted Node.js server. 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: Command a premium, because specialists are scarce and legacy knowledge is hard to find.
• Next.js developer rates: Span a wider range, thanks to a much larger and more competitive talent pool.
• Migration cost (medium Gatsby site to Next.js): Typically $15,000-50,000 depending on complexity, based on our own project scoping.
• Ongoing maintenance (Gatsby): Higher, due to dependency management and plugin fixes.
• Ongoing maintenance (Next.js): Lower, with simpler upgrade paths.

The hidden cost of staying on Gatsby is technical debt that grows daily. The longer you wait, the harder the migration gets, since the Gatsby ecosystem keeps deteriorating.

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

Migration Path: Gatsby to Next.js

Based on our own migrations to Next.js, including the WordPress-to-Next.js rebuild for SleepDr.com, here's a repeatable approach for moving off Gatsby:

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 image handling. Gatsby's image pipeline was genuinely excellent: blur-up placeholders, responsive srcsets, and lazy loading. The good news is next/image handles all of this now, though the API is different. You'll need to update every image reference.

When Next.js Isn't the Answer

Next.js isn't the right choice for every project.

If you need pure simplicity for a blog or docs site, consider Astro. Astro ships zero JavaScript by default and has strong content collection support. For content-driven sites where you don't need React's interactivity, Astro will generally 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 own ecosystems.

But if you need React, a mix of static and dynamic content, strong performance, and a framework built for the long haul, Next.js is the obvious choice in 2026.

The Verdict

Next.js wins, and it hasn't been close since 2022.

Gatsby pioneered important ideas in the React ecosystem: build-time optimization, image processing pipelines, and 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 strong:

• RSC and the App Router give Next.js an architectural edge Gatsby can't match
• Bundle sizes are typically far smaller, thanks to Server Components (see React's RSC docs)
• Core Web Vitals scores are consistently better
• ISR and PPR provide rendering flexibility Gatsby never reached
• The ecosystem is thriving, not stagnating

The business arguments are just as clear:

• Lower total cost of ownership
• A larger talent pool
• Active development and support from Vercel
• Clear upgrade paths for the years ahead

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 costly it gets.

Need help planning that migration? Let's talk.

-- 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 keeps declining. 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 to 200 pages, expect 4 to 8 weeks of development time. Larger sites with complex data relationships, custom plugins, or heavy GraphQL usage can take 8 to 16 weeks. The biggest factors are the number of custom Gatsby plugins you use and how deeply you've built into Gatsby's GraphQL data layer.

Is Next.js harder to learn than Gatsby?

The App Router and Server Components have a learning curve, especially if you're coming from Gatsby's pages-based model. But the underlying model is simpler in the end. You fetch data directly instead of going through a GraphQL layer, and you write components that run on either the server or the client. Most developers find Next.js easier to reason about once they get past the initial RSC concepts.

Can I deploy Next.js without Vercel?

Yes. Next.js can deploy to AWS (using SST, Amplify, or a custom setup), Cloudflare Pages, DigitalOcean, Railway, Fly.io, or self-hosted on any Node.js server. Vercel gives 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 content-driven sites such as blogs, docs, or marketing pages with little interactivity, Astro is often the better choice, since 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; see 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 around $15,000 for a simple marketing site to $50,000 or more for complex applications with custom data pipelines, e-commerce integration, or internationalization. The cost depends heavily on the number of Gatsby plugins that need replacing, the complexity of your GraphQL queries, and whether you modernize the architecture during the migration.

Does Next.js support static export like Gatsby?

Yes. Running next build with output: 'export' in your next.config.js builds a fully static site that can be hosted anywhere: S3, GitHub Pages, or 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 see the benefits of ISR and Server Components.

What happened to Gatsby Cloud?

Gatsby Cloud was shut down in Q1 2024, roughly a year after Netlify's acquisition. Users were moved to Netlify's standard hosting. This was a real blow, because Gatsby Cloud provided optimized builds, incremental builds, and preview functionality tightly tied to Gatsby's architecture. Without it, build times on standard CI/CD platforms are noticeably worse.