
Next.js vs Gatsby for Ecommerce in 2026: What the Release Data Says
For a new ecommerce build in 2026, choose Next.js. Gatsby is not abandoned, but it is in maintenance mode: it has published 2 stable releases this year against 51 for Next.js, and its last release is almost eight months old. For a store, the deciding difference is data freshness. Gatsby sources the catalog at build time, while Next.js can refresh a single product page when a Shopify webhook fires. If you already run a Gatsby store that builds fast and has no roadmap pressure, you do not need an emergency migration. You do need a trigger list, and this article gives you one.
Key takeaways (checked against npm, GitHub and official docs on October 5, 2026):
- Latest Gatsby is 5.16.1, released February 10, 2026. Latest Next.js is 16.3.8, released September 30, 2026.
- Gatsby added React 19 support in version 5.16 on January 26, 2026. React 19 went stable on December 5, 2024, so the wait was more than 13 months.
- The Gatsby repository received 113 commits this year up to October 5. Of the 100 most recent, 80 were authored by dependency bots.
- Gatsby still sees about 1.26 million npm downloads a month, down only 28% from September 2022. A large installed base is still running it.
- We moved increas.io itself from Gatsby to Next.js between mid-2022 and mid-2023. Our team has shipped 120+ Next.js projects.
How active is each framework in 2026?
Next.js ships roughly every week. Gatsby ships a few times a year. We pulled the release history of both packages from the npm registry today and counted stable versions, including patch releases on older maintained lines.

| Signal | Gatsby | Next.js |
|---|---|---|
| Latest stable version | 5.16.1 (February 10, 2026) | 16.3.8 (September 30, 2026) |
| Latest major version | 5.0, November 2022 | 16.0, October 2025 |
| Stable releases in 2022 | 73 | 33 |
| Stable releases in 2025 | 6 | 82 |
| Stable releases in 2026, to October 5 | 2 | 51 |
| npm downloads, September 2022 | 1.75 million | 13.8 million |
| npm downloads, September 2026 | 1.26 million | 243.4 million |
| Minimum Node.js version | 18 | 20.9 |
Two caveats on reading this. npm downloads count installs, including every CI run, so they measure activity and not the number of live sites. And release count alone is not quality: a framework can be stable and quiet. The next section looks at what kind of quiet this is.
Is Gatsby dead in 2026?
No. Gatsby is maintained, but it is no longer developed in any meaningful sense. Netlify acquired Gatsby Inc. on February 1, 2023 and in August 2023 announced the sunset of Gatsby Cloud, promising maintenance of the open-source framework with a "focus on stability and support for large scale projects." The commit history shows what that has meant in practice.
Commits to the default branch of the Gatsby repository, from the GitHub API:
| Year | Commits |
|---|---|
| 2022 | 1,354 |
| 2023 | 624 |
| 2024 | 115 |
| 2025 | 48 |
| 2026, to October 5 | 113 |
Activity picked up in 2026, which is a fair point in Gatsby's favor. But 80 of the 100 most recent commits come from Dependabot and Renovate. The work is dependency bumps, security patches and CI fixes. That keeps existing sites safe. It does not add features.
The cost of this mode shows up as lag behind the React ecosystem. Gatsby's 5.16 release notes announce official React 19 and Node.js 24 support, dated January 2026. React 19 was released on December 5, 2024. A team on Gatsby waited more than 13 months before it could adopt React 19 with official support. Next.js 16, released in October 2025, runs on React 19.2.
The minor release cadence tells the same story: 5.13 in December 2023, 5.14 in November 2024, 5.15 in August 2025, 5.16 in January 2026. Plan around two minor releases a year and assume each one is a compatibility release.
Why does this matter more for a store than for a content site?
Because a store's data changes between builds, and Gatsby's model ties data to the build. The official gatsby-source-shopify plugin pulls the catalog through Shopify's bulk operations API while the site builds. A price or stock change reaches a statically generated page after the next build finishes, not before. The plugin's README still documents priority-build logic for Gatsby Cloud, a product Netlify has since sunset. The plugin itself has had one release in 2026 and sees about 4,700 weekly downloads, compared with about 94,000 for Shopify's own Hydrogen package.
Gatsby does have other rendering modes. Deferred Static Generation builds a page on first request, and getServerData renders on every request. What its docs do not describe is the middle ground a catalog needs: keep the page static, and refresh it when the product changes. The common workaround is to fetch price and stock in the browser, which costs a second round trip on every product page.
In Next.js that middle ground is a documented, first-class feature. Tag the product fetch, then invalidate the tag from a Shopify products/update webhook. This is Next.js 16.3 syntax, typechecked against next@16.3.8:
// lib/shopify.ts
export async function getProduct(handle: string) {
const res = await fetch(process.env.SHOPIFY_STOREFRONT_URL!, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Shopify-Storefront-Access-Token': process.env.SHOPIFY_STOREFRONT_TOKEN!,
},
body: JSON.stringify({ query: PRODUCT_QUERY, variables: { handle } }),
next: { tags: [`product-${handle}`] },
})
return res.json()
}// app/api/shopify/webhook/route.ts
import { createHmac, timingSafeEqual } from 'node:crypto'
import { revalidateTag } from 'next/cache'
export async function POST(request: Request) {
const body = await request.text()
const expected = createHmac('sha256', process.env.SHOPIFY_WEBHOOK_SECRET!)
.update(body, 'utf8')
.digest()
const received = Buffer.from(
request.headers.get('x-shopify-hmac-sha256') ?? '',
'base64'
)
if (
received.length !== expected.length ||
!timingSafeEqual(expected, received)
) {
return new Response('Invalid signature', { status: 401 })
}
const product = JSON.parse(body) as { handle: string }
// Serve the cached page while a fresh one renders in the background
revalidateTag(`product-${product.handle}`, 'max')
return Response.json({ revalidated: true })
}Three details from the revalidateTag reference that matter in production:
- Since Next.js 16 the second argument is required.
'max'serves the stale page while a fresh one renders. For a price that must never be shown stale, pass{ expire: 0 }and the next request blocks until fresh data is in. - The call only marks data as stale. Regeneration starts on the next request for that page, so a webhook burst after a bulk price edit does not trigger 20,000 renders at once.
- When self-hosting on several instances, the default file-system cache is per instance. The ISR guide says on-demand revalidation only reaches the instance that receives the call unless you configure a shared cache handler.
Shopify signs every webhook delivery with a Base64 HMAC in the X-Shopify-Hmac-Sha256 header, per the webhooks documentation. Verify it against the raw body, as above, before touching the cache.
Vercel's Next.js Conf 25 opening keynote (October 2025, 44 minutes). The embed starts at 14:16, the segment on instant navigations and Cache Components in Next.js 16.
What did we learn moving our own site off Gatsby?
That the rebuild model is fine until the data outgrows it. increas.io ran on Gatsby: the Wayback Machine snapshot from May 21, 2022 shows Gatsby markup, and the snapshot from June 1, 2023 shows Next.js. We were an early Jamstack shop and still keep a Gatsby template we built in the portfolio, so this was not a decision made out of dislike for the tool.
Our blog is an honest example of where rebuild-on-publish still works. A publish in our headless CMS fires a webhook, Vercel rebuilds the site, and the post is live about 90 seconds later (timed on September 28, 2026). With fewer than 20 posts and one publish a week, that is good enough, and we have not replaced it with per-page revalidation.
A catalog is a different load. The trouble starts when merchandising edits prices daily, stock moves by the minute, and the site has thousands of product pages. Every change either waits for a build or forces a client-side fetch, and neither gets cheaper as the catalog grows.
When should a Gatsby store stay on Gatsby?
When none of the triggers below apply. Gatsby 5.16 supports React 19 and Node.js 24, security patches are landing, and a rewrite has a real cost. Staying is a legitimate engineering decision if you treat the stack as frozen.
Start planning a migration when any of these become true:
- Build time is now a business constraint. Merchandising waits on deploys, or a price change takes more than a few minutes to show up.
- You need something the React ecosystem shipped recently. Official React 19 support took Gatsby more than 13 months.
- A dependency you rely on drops Gatsby. Check the release dates of your source and image plugins the way we did above. One release a year is a warning.
- Hiring is getting harder. Candidates read release histories too, and 2 releases in a year is easy to find.
- The roadmap includes personalization, B2B pricing or logged-in catalogs. Per-customer data pushes Gatsby toward server rendering on every request, which gives up the main reason to use it.
If none of that is true today, set a calendar reminder for the next Node.js LTS cutoff and re-check.
What does a Gatsby to Next.js migration involve?
Mostly moving data fetching out of the GraphQL layer, because the React components largely carry over. The mapping we work from:
| In Gatsby | In Next.js 16 (App Router) |
|---|---|
createPages in gatsby-node.js | generateStaticParams in the route file |
| Page queries against the GraphQL data layer | fetch inside Server Components |
gatsby-source-shopify (Admin API, at build) | Storefront API calls, cached and tagged |
defer: true (DSG) | Pages generated on first request, then cached |
getServerData | Dynamic rendering |
gatsby-plugin-image | next/image |
wrapRootElement in gatsby-browser.js / gatsby-ssr.js | app/layout.tsx |
The risk is in what the table leaves out. Gatsby plugins often hide real behavior: sitemap generation, redirects, canonical tags, analytics. Each one needs an explicit replacement, and URL parity needs a test before launch, including trailing slashes, which Gatsby and Next.js handle differently by default. A store that comes back faster but loses its category rankings has failed the migration.
On timeline: our Next.js team typically ships a Next.js 16 marketing or content site in 4 to 10 weeks, and a full web application in 3 to 6 months depending on integrations. A storefront migration is scoped per project. Catalog size, the count of Gatsby plugins to replace and the amount of cart or account logic in the front end set the number, and we return a fixed-scope estimate within 48 hours of receiving a brief.
Should a Shopify store pick Next.js or Hydrogen instead?
Hydrogen, if the storefront is Shopify-only and you want hosting included. Next.js, if commerce is one part of a larger site with content, apps or several back ends. Hydrogen runs on React Router and Shopify's Oxygen hosting, with custom builds from $3,400 and 3 to 7 weeks on our side. We covered the cost of ownership, including the quarterly upgrade calendar, in Is Shopify Hydrogen worth it in 2026?
Gatsby is not on that shortlist for a new store. The data above is the reason: a storefront is a multi-year commitment, and one of these frameworks shipped 51 releases this year while the other shipped 2.
Running a Gatsby storefront and not sure whether it has hit a trigger? Send us the repo size and build time and we will tell you whether to stay, migrate to Next.js or move to Hydrogen.
Do you want secure, fast website or application?