Astro vs Gatsby

Last reviewed Aug 26, 2026 · 744 words

Gatsby is the one static site framework I tell people to migrate away from, and Astro is where most of them land. The two overlap almost perfectly on paper: both produce static HTML, both let you write React, both pull content from Markdown or a headless CMS, both are MIT-licensed and sit in the blogging category. The difference is that Gatsby's big idea, a GraphQL data layer in front of every content source, turned out to cost more in build time and mental overhead than it returned, and the project stopped moving fast enough to fix that. Astro shipped the same outcome with a simpler mechanism and kept shipping.

Gatsby's momentum problem is not a rumour

Netlify bought Gatsby in early 2023, shut down the Gatsby Cloud hosting product later that year, and the framework has been on maintenance-grade releases since. The catalogue numbers show the shape of it: Gatsby launched in 2015 and holds 55,942 GitHub stars; Astro launched in 2021 and has already passed it at 62,054. Plugin authors follow users, so the "rich plugin ecosystem" on Gatsby's highlight list increasingly means plugins pinned to old React and old Node versions that you inherit rather than choose.

The GraphQL layer was the point, and it is the tax

Every Gatsby site queries its own content through GraphQL, even a ten-post blog reading Markdown from disk. That uniformity was genuinely clever when you had five sources and wanted one query language over all of them. It also means every build runs a schema inference pass and every page component carries a query. The catalogue's 1,024 MB minimum RAM for Gatsby against Astro's 512 MB understates the gap on real sites; Gatsby builds with a few thousand image-heavy pages are where people first learn what an out-of-memory error in Node looks like.

Astro's content collections handle the common case directly: a folder of Markdown or MDX, a schema declared in TypeScript, typed front matter checked at build time, no query language. For remote sources, Astro's content layer takes loader functions that fetch from an API into the same collections, which covers most of what gatsby-source-* plugins did without a graph in the middle.

Zero JavaScript by default versus React everywhere

A Gatsby page is a React app that happens to be pre-rendered; the React runtime ships to every visitor whether the page needs it or not. Astro inverts that. Pages are HTML by default, and you opt into interactivity per component with a client: directive, so <Search client:load /> hydrates the search box and nothing else on that page. For a content site this is the difference between a page weight measured in kilobytes and one carrying a framework, and it is why Astro sites tend to pass Core Web Vitals without tuning. Gatsby's performance work (image processing, route prefetching, code splitting) is real, but it is effort spent offsetting a runtime that Astro simply does not send.

Migration: the React survives, the queries do not

Astro renders React components natively, so a Gatsby site's component library moves over largely intact. What does not transfer is anything touching useStaticQuery, page creation in gatsby-node.js, or gatsby-plugin-image; those become content collections, getStaticPaths, and Astro's built-in <Image> component. Budget 2 or 3 days for a medium blog, longer if you built heavily on source plugins for a CMS. If you are re-evaluating the whole field rather than just these two, Astro vs Hugo covers the case for leaving Node entirely.

Decision table

What I'd do

Build new on Astro. For an existing Gatsby site, I would set a trigger rather than migrate on principle: the next time a Node upgrade, a security advisory, or a broken plugin forces you to touch the build, do the port to Astro then. Spending that same afternoon patching Gatsby only buys you the next forced afternoon.