Back in 2019, I migrated my entire blog to Gatsby.js. By 2023, I was migrating away from it. This post, originally a love letter to Gatsby, is now a retrospective from someone who used it heavily and moved on.

Should you use Gatsby for a new project in 2026? No. Pick one of the alternatives below. Read on for why, and what Gatsby got right while it was the best option in town.

Gatsby in 2026: Where Things Stand

Netlify acquired Gatsby in February 2023. Within months, most of the core team was gone. Releases slowed sharply. The plugin ecosystem, once Gatsby’s biggest strength, is now largely unmaintained, with many popular plugins abandoned for years.

Gatsby is not officially dead. The site still runs, the docs are still up, and you can still npm install gatsby. But it is in maintenance mode at best. Even keeping an existing Gatsby site running is non-trivial: every Node.js upgrade tends to surface a new round of dependency and plugin breakage that nobody is racing to fix.

If you’ve been Googling “is Gatsby still good?”, that’s the honest read.

Should You Use Gatsby for a New Project in 2026?

No. There is no remaining scenario where Gatsby is the best choice for a new project. Pick one of these instead:

• Astro: content-heavy sites, blogs, marketing pages, documentation. Ships near-zero JavaScript by default. This blog runs on Astro.
• Next.js: full applications with auth, databases, API routes, and React Server Components.
• TanStack Start and TanStack Router: when you want first-class type safety, fine-grained data loading, and a framework that doesn’t hide too much from you.

Each of these solves the problems Gatsby solved (file-based routing, optimized images, MDX, performance-by-default) without the dead-ecosystem risk.

Why I Migrated Away from Gatsby

Three things pushed me off Gatsby:

Build times. As the post count grew, full builds got painful. Incremental builds helped, but never felt reliable on a content-heavy blog. Astro’s content collections solved this for me without needing a new mental model.

Plugin churn. The migration from gatsby-image to gatsby-plugin-image was the kind of breaking-change cycle that ate full days. Plugins I depended on stopped getting updates. Every Gatsby major version came with a “which plugins are still maintained?” audit.

Weight. Gatsby’s GraphQL data layer was elegant, but heavy for what a blog actually needs. Astro’s content-first model (markdown files in, HTML out, minimal JavaScript shipped) fit the goal better than Gatsby’s all-roads-lead-through-GraphQL design.

By 2023, the cost of staying on Gatsby was higher than the cost of moving. Once Netlify’s restructuring happened, the decision was easy.

What Gatsby Got Right

It’s worth understanding what Gatsby pioneered, because a lot of what feels standard in modern web frameworks today started, or got popularized, in Gatsby.

A React-based static site generator. Before Gatsby, most static site generators were tied to languages or templating systems React developers didn’t use day-to-day: Hugo, Jekyll, Hexo. Gatsby let React developers stay in React. That sounds obvious today because every modern framework does it; in 2017 it was the unlock.

File-based routing. Drop a component into src/pages/, get a route. No config. Next.js shipped it around the same time, but Gatsby helped make it the default expectation. Today’s frameworks like Next.js, Astro, and TanStack Start all assume it.

A plugin model for the boring stuff. Analytics, sitemaps, RSS, image optimization, sourcing data from a CMS: all one-line installs. The model didn’t survive in newer frameworks (which prefer first-party features over a plugin marketplace), but the bar Gatsby set for “this should just work” carried forward.

Image handling done right. gatsby-image (later gatsby-plugin-image) gave you responsive sources, lazy loading, and the LQIP blur-up effect with a single component. Every modern framework now has an equivalent: <Image> in Next.js, <Image> in Astro. Gatsby was first.

MDX as a first-class citizen. Gatsby was where most React developers first met MDX. It’s now everywhere: Astro, Next.js, Docusaurus, and Storybook all support it natively.

Performance defaults. Lighthouse scores in the 90s out of the box. Prefetching of links on the page. Critical CSS inlined. Most of these defaults are now standard, but Gatsby was the framework that made them the floor instead of the ceiling.

Gatsby was the right tool in 2019, and many of the patterns it pushed are now table stakes. For a new project in 2026, the answer is no: pick Astro for content, Next.js for apps, or TanStack Start when you want a leaner, more explicit alternative.

If you’re stuck on an aging Gatsby site, the migration paths to Astro and Next.js are both well-trodden. The longer you wait, the more brittle the dependency chain gets.