Why My Gatsby Site Takes 47 Minutes to Build

Memory Leaks and Production Nightmares

Our e-commerce site (14,000 product pages from Contentful + 2,400 Shopify products) runs on Gatsby 5.12.0. Started noticing weird shit around October 2024 when our Senior Frontend Dev Jake upgraded from 5.8.0. Builds would randomly fail at step "Building static HTML for pages" with:

<--- Last few GCs --->
[23847:0x5555e8b6c000] 185623 ms: Mark-Sweep 2048.0 (2070.8) -> 2048.0 (2070.8) MB, 1049.2 / 0.0 ms (average mu = 0.136, current mu = 0.000) allocation failure scavenge might not succeed

<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Documentation says set NODE_OPTIONS="--max_old_space_size=8192". We tried 4GB, 8GB, 16GB on our GitHub Actions runners (Standard_DS3_v2). Still crashes around page 8,127 every fucking time. Something's leaking during SSR but the Gatsby team won't respond to the GitHub issue we opened eight months ago. Our DevOps team is livid about the wasted CI minutes.

The official Gatsby docs acknowledge the problem but offer no real solutions. Community threads are full of people hitting the same wall. Even Netlify's forums show builds failing with exit code 137.

The Shopify Time Bomb

Worse problem: gatsby-source-shopify is about to break. Plugin uses Shopify Admin API version 2024-01, which gets deprecated January 1, 2025. New version 2024-07 has breaking changes to product variants schema.

The plugin hasn't been updated since March 2024. Last maintainer left after Netlify layoffs. No one's fixing it. The npm package shows 10,000+ weekly downloads but zero maintenance. Plugin repository issues keep piling up with no responses.

Our entire product catalog (2,400 products across 8 categories) will go dark in 22 days. Had to fork the plugin and patch it ourselves. Spent 3 days with Sarah from the backend team figuring out the new GraphQL schema just to keep builds working. Management still doesn't understand this is a P0 issue. Shopify's API versioning docs show the deprecation timeline. Other devs are reporting the same panic across forums.

Build Performance Death Spiral

Started at 6 minutes 23 seconds in August 2022 with 8,000 pages. Now 47 minutes 12 seconds with 14,000 pages on identical hardware. That's not linear scaling - something's completely fucked in gatsby-node.js.

I profiled it with npx --node-options="--inspect" gatsby build and watched Chrome DevTools. Memory usage climbs from 412MB to 6.8GB during "source and transform nodes". Never comes down. Garbage collection runs every 28-35 seconds but only frees 180-280MB. The memory leak is real. Memory profiling guides show the same pattern. Performance optimization docs are outdated.

Compare that to our Next.js test branch: 4 minutes for the same content. No memory issues. Next.js build performance is consistently faster. Framework benchmarks confirm the difference. But migration means rewriting 47 GraphQL queries and our entire image handling pipeline. Migration guides exist but they're not comprehensive.

February 2023: The Beginning of the End

Netlify acquired Gatsby in February 2023. Kyle Matthews, Gatsby's co-founder, posted this optimistic corporate bullshit on their blog:

"Many performance innovations specifically for large, content-heavy websites, preview, and collaboration workflows, will be incorporated into the Netlify platform and, where relevant, made available across frameworks."

Translation: We got acquired and have no fucking clue what happens to our users. The "where relevant" part should have been a red flag.

Matt Biilmann (Netlify CEO) was more honest in interviews. Told The New Stack that Gatsby "weren't winning the framework battle against Vercel" and were "boxed in by us." Basically admitted they bought Gatsby to kill the competition. Industry analysis called it an "acquihire." Developer communities were skeptical from day one.

August 2023: The Lies Unravel

By August, a Netlify support engineer casually posted that incremental builds wouldn't be ported to Netlify. You know, the ONE feature that made Gatsby Cloud worth paying for.

One user replied: "Huge blow to Gatsby Cloud customers. The incremental build speed was exactly why we switched from Netlify to Gatsby Cloud in the first place."

No fucking shit. We paid $400/month for Gatsby Cloud specifically for incremental builds (went from 47 minutes to 3 minutes for content updates). Netlify's equivalent Business plan is $800/month and builds take 6x longer because they don't understand Gatsby's internal caching. We basically got screwed twice.

October 2023: The Mass Exodus

Fred Schott tweeted: "There have been zero commits to the Gatsby repo in the last 24 days."

Lennart Jörgens (ex-Gatsby dev) replied: "Don't expect the one person remaining to do all the work."

One. Fucking. Person.

Kyle Matthews left sometime in 2024. Now he's working at Electric, not even web frameworks anymore. The guy who created Gatsby gave up on it. His departure was quiet - no blog post, no farewell. His GitHub profile shows he switched to database infrastructure. GitHub commits stopped abruptly.

The Current State of Abandonment

From the official Netlify response in November 2023:

"While we don't plan for Gatsby to be where the main innovation in the framework ecosystem takes place, it will be a safe, robust and reliable choice."

"Safe, robust and reliable" while plugins break, memory leaks go unfixed, and the Shopify integration dies in 22 days.

Latest Gatsby release (5.14.0) from November 2024 is just dependency updates and removing telemetry. They stopped tracking usage because they don't want to know how bad it is. Release notes are depressing. NPM download stats show declining adoption.

Compare the GitHub activity:

• Next.js: 50+ commits per week
• Gatsby: 2-3 commits per month, mostly dependabot
• Community discussions are just migration questions
• Issue backlog keeps growing with no responses
• Framework benchmarks exclude Gatsby entirely

This is what "stable and reliable" looks like when a company acquihires your framework to death.

The Plugin Fork Hell

Since no one's maintaining gatsby-source-shopify (last commit March 2024), I forked it on December 3rd. Had to update the Admin API from version 2024-01 to 2024-07. The breaking changes are fucking brutal and took me 3 days to figure out:

Old schema:

product {
  variants {
    compareAtPrice
  }
}

New schema:

product {
  variants {
    compareAtPriceV2 {
      amount
      currencyCode
    }
  }
}

Every fucking price field is now an object with currency codes. Broke our entire product display logic across 12 page templates. Spent 2 days with Sarah from backend updating all the GraphQL fragments. Had to write a migration script to update 2,400 product pages.

Now I maintain a private fork with 8 commits ahead of the dead upstream. Published it to our internal npm registry because who knows what other Shopify fields will break. Fun times.

Memory Limit Russian Roulette

Our production builds run in GitHub Actions with 7GB runners. Set NODE_OPTIONS=\"--max_old_space_size=6144\" to use 6GB for Gatsby. Still crashes 1 in 5 builds at exactly this error:

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory

Page 8,127 every fucking time. I checked - it's just a regular product page for "Men's Blue Cotton T-Shirt" from our apparel category. Nothing special about the GraphQL query, the page template, or the imported components. Same structure as 8,126 other products.

The workaround? Retry the build and hope. Usually passes on attempt 2-3, sometimes takes 4 tries. Our GitHub Actions workflow has retry-on-error: 3 just for Gatsby builds. I had to explain to DevOps why our "static site generator" needs retry logic. Embarrassing doesn't begin to cover it.

Why I Can't Just Migrate Right Now

The database problem: We have custom CMS integration built on Gatsby's data layer. 47 GraphQL queries across 12 page templates. Each query joins data from 3-4 different sources (Contentful, Shopify, our PostgreSQL API).

Converting them to Next.js API routes means:

1. Moving GraphQL logic to API endpoints
2. Replacing useStaticQuery with fetch calls
3. Handling loading states (Gatsby pre-renders everything)
4. Updating all our TypeScript interfaces

The migration documentation exists but glosses over complex data integration. Community guides provide real examples.

That's 3-4 weeks minimum if everything goes smoothly (it won't). Management approved 5 days for "performance improvements" back in November. I explained that's not enough time to do it right, they said "just make it faster."

The politics problem: CTO keeps asking "what's broken that needs fixing?" during our weekly tech debt meetings. Hard to explain that we're one npm update away from total failure. Site loads fine for users, so why spend a month rewriting it? He doesn't see our Slack alerts at 2AM when builds fail.

Marketing team is already asking for new features (product bundles, better search). They don't understand that we're in maintenance mode trying not to break existing functionality. They think web development is "just change the text."

The Cost of Staying

CI/CD costs: $340/month for 47-minute builds on GitHub Actions (Standard_DS3_v2 runners). We burn through 890 minutes per day just for main branch deploys. Next.js would cost $80/month for the same workload.

Developer time: I spend 6-8 hours per week fighting Gatsby issues. Memory debugging with Chrome DevTools, forking and patching plugins, carefully testing dependency updates so they don't break things. That's roughly $15k/year of my salary spent on framework babysitting instead of shipping features.

Opportunity cost: Can't use modern React patterns like Server Components. Stuck with Gatsby's data layer instead of React Query. Missing out on Vercel's deployment optimizations. Performance monitoring shows what we're missing.

Technical debt: Every month we delay migration adds more custom code tied to Gatsby's architecture. The GraphQL queries get more complex. The plugin forks accumulate more custom patches. Code complexity metrics keep climbing. Dependency analysis shows an increasingly fragile foundation.

The Plan (If I Ever Get Time)

1. Week 1: Next.js setup, convert 5 basic pages
2. Week 2: Move complex pages with data dependencies
3. Week 3: Image optimization and SEO features
4. Week 4: Testing, deployment pipeline, team training

Already have a test branch (feature/nextjs-migration) with the home page and about page converted. Build time went from 47 minutes 12 seconds to 3 minutes 8 seconds. Jake from frontend helped convert the product listing page and we got it working with proper SEO meta tags.

But until management prioritizes it, I'm stuck maintaining this architectural nightmare. At least it's job security. Every time a dependency breaks, I become more valuable to the company. Dark job security strategy.