Every headless project on Shopify eventually reaches the same fork in the road. The catalog, the cart and the checkout are going to live on Shopify either way. The question is what renders the storefront in front of them, and in 2026 that question almost always comes down to two answers: Shopify Hydrogen or Next.js Commerce.
Both are React. Both talk to the same Storefront API. Both can produce a fast, well ranked, conversion friendly store. They diverge on hosting, on hiring, on how quickly new Shopify features reach your customers, and on who is responsible when something breaks at 2am on Cyber Monday. This guide works through the hydrogen vs next commerce decision the way an engineering lead and a merchandising lead would work through it together.
In short
- Hydrogen is the shortest path to a Shopify native storefront. It ships with Shopify’s own primitives for cart, analytics, customer accounts and search, and it deploys to Oxygen with one command.
- Next.js Commerce is the shortest path to a storefront that is more than a store. If the same codebase has to serve editorial, community, B2B portals or a subscription flow, Next.js has the wider ecosystem.
- Feature lag is the underrated tiebreaker. New Shopify capabilities land in Hydrogen first, and Next Commerce teams frequently write their own bindings for the same feature weeks or months later.
- Hiring changes the maths more than benchmarks do. There are far more Next.js developers on the US market than Hydrogen specialists, and that gap shows up in salaries, agency rates and how fast you can backfill a departure.
- Neither is a performance cheat code. Both frameworks lose to a well tuned Shopify theme if the team fills them with client side scripts, unoptimized images and third party tags.
Why this choice matters in 2026
Headless stopped being a novelty around 2023 and became a normal, if expensive, option for mid market retailers. What changed by 2026 is that both candidate frameworks matured past their awkward phase, which removed the easy excuse of “neither is production ready”. Now the decision is a genuine trade off rather than a wait and see.
Hydrogen sits on React Router v7, having migrated off Remix v2 in late 2024, and Shopify moved it to calendar based versioning with quarterly headline releases. That versioning change matters more than it sounds. Projects that publish on a predictable quarterly cadence tend to be infrastructure that a vendor intends to support for years, not experiments looking for product market fit.
Next.js Commerce, maintained by Vercel at the vercel/commerce repository, moved to the App Router with React Server Components and server actions, and remains the most starred Next.js commerce starter on GitHub with more than 11,000 stars as of mid 2026. It is a reference implementation rather than a framework, which is both its strength and the source of most of the confusion around it.
The stakes are simply higher than they were. A storefront rebuild for a mid market US retailer typically runs six figures and eats nine to eighteen months of roadmap. Choosing wrong does not usually kill a business, but it does mean a team spends a year building capabilities that the other option would have handed them on day one. Before committing to either, it is worth revisiting how to choose the right e-commerce platform for your store, because a surprising number of headless projects turn out to be solving a platform problem rather than a frontend one.
Key terms and definitions
Half the arguments about headless commerce are people using the same word for different things. Worth pinning down the vocabulary before comparing anything.
Storefront API. Shopify’s public GraphQL API for reading products, collections and content, and for creating and mutating carts. Both Hydrogen and Next.js Commerce consume it. This is the shared foundation, and it is why the two options are more similar than the marketing suggests.
Hydrogen. Shopify’s opinionated React framework for custom storefronts, currently built on React Router v7. It bundles Shopify specific components, hooks and server utilities so that a developer does not hand roll cart state, session handling or analytics events.
Oxygen. Shopify’s global edge hosting platform, purpose built for Hydrogen storefronts, with multiple deployment environments so teams can preview a branch before it reaches production. Oxygen is optional. Hydrogen runs on Vercel or Cloudflare Workers too, though most production builds pair Hydrogen with Oxygen because that combination is what Shopify supports end to end.
Next.js Commerce. Vercel’s official commerce starter template, currently Shopify first, built on the Next.js App Router. It is code you clone and own, not a dependency you upgrade. That distinction drives most of the long term maintenance difference between the two paths.
Feature lag. The gap between Shopify shipping a capability and your storefront being able to use it. Low for Hydrogen, variable for Next.js Commerce, and the single most common source of post launch frustration in headless projects.
How each framework works in practice
The architectural diagrams look nearly identical. The day to day developer experience does not.
The Hydrogen request lifecycle
A request hits Oxygen at the edge. Hydrogen’s server loader queries the Storefront API, and Shopify’s own caching primitives decide what gets cached at the edge and for how long. The response streams to the browser as React Server Components resolve. Cart mutations run through Hydrogen’s cart handler, which wraps the Storefront API cart mutations so developers are not writing raw GraphQL for every add to cart.
What you get for free is the interesting part: customer account authentication, a search and predictive search implementation, Shopify analytics events wired to the right places, and a consent management hook that respects the shopper’s privacy choices. Each of those is a week or more of work if you build it yourself.
The Next.js Commerce request lifecycle
A request hits Vercel’s edge network. A React Server Component fetches from the Storefront API through a thin, hand written data layer that lives in your repository. Product pages typically use incremental static regeneration so the catalog is served as cached HTML and regenerated on demand. Cart mutations run through server actions, which is a clean pattern but one your team writes and maintains.
The template gives you a working reference for all of this, including dynamic Open Graph images generated per product and edge runtime routes for low latency worldwide. What it does not give you is a versioned dependency that keeps pace with Shopify. When Shopify changes something in the Storefront API, someone on your team notices and updates the data layer.
Where the cart actually lives
In both cases the cart lives on Shopify, identified by a cart ID stored in a cookie. This trips up teams who assume headless means they now own cart state. They do not, and that is a good thing, because it means discount codes, gift cards, market pricing and checkout all keep working without a custom implementation.
The difference is ergonomic rather than architectural. Hydrogen hands you an optimistic cart with the loading states already handled. Next.js Commerce hands you a competent example of one, which your team then extends for quantity rules, bundles, subscriptions or whatever your merchandising team asks for next quarter.
How deploys and previews differ
Oxygen gives every branch a preview URL and ties deployments to the Shopify admin, so a merchandiser can see a staging storefront without asking an engineer. Vercel does the same thing with preview deployments, and does it slightly better in terms of collaboration tooling and comment threads on preview builds.
The practical difference is who holds the bill and the support contract. With Oxygen, hosting is part of the Shopify relationship. With Vercel, it is a separate vendor, a separate invoice and a separate escalation path when latency spikes.
Head to head: where each one wins
Below is the comparison that actually drives decisions, stripped of the marketing framing that both vendors apply to their own product.
| Dimension | Shopify Hydrogen | Next.js Commerce |
|---|---|---|
| What you adopt | A versioned framework you upgrade | A template you clone and own |
| Routing foundation | React Router v7 | Next.js App Router |
| Default hosting | Oxygen, included with Shopify plans | Vercel, billed separately |
| Shopify feature lag | Lowest, Shopify ships bindings first | Variable, often team implemented |
| Cart, accounts, search | Provided as first party primitives | Reference implementation, you extend it |
| Non commerce pages | Workable but not the design centre | Strong, the wider Next.js ecosystem applies |
| Developer supply in the US | Narrow, Shopify specialists | Broad, any senior React developer |
| Portability off the stack | Lower, Shopify specific abstractions | Higher, mostly standard Next.js |
| Best fit | Shopify first brands optimising commerce | Brands where the store is one surface of many |
Performance is a wash, and that surprises people
Both frameworks stream server rendered React from an edge network in front of the same API. In controlled comparisons the difference in Largest Contentful Paint between a well built Hydrogen store and a well built Next.js Commerce store is small enough to be noise next to the effect of image weight and third party scripts.
The realistic performance conversation is not Hydrogen versus Next. It is whether your team disciplines the tag manager, ships properly sized images and resists the urge to hydrate the entire page. Teams that lose that fight ship a slow headless store on either framework, which is the most expensive way possible to end up slower than the Shopify theme you replaced.
Developer availability is the quiet decider
Ask any US retailer who has tried to backfill a headless role. The pool of engineers who have shipped production Next.js is very large. The pool who have shipped production Hydrogen is a fraction of that, and they command a premium, whether hired directly or through an agency.
This cuts both ways. A Hydrogen specialist arrives already knowing Shopify’s data model, which is often worth more than raw React seniority. A generalist Next.js hire is cheaper and easier to find, then spends their first two months learning why Shopify’s metafields, markets and selling plans behave the way they do.
Feature lag compounds over years
This is the argument that tends to win rooms. When Shopify ships a new capability, whether that is a change to customer accounts, a new analytics surface or an agentic checkout primitive, the Hydrogen binding tends to land in the same release cycle. Next.js Commerce teams read the API changelog and write their own.
One instance of that is a sprint. Twelve instances over three years is a standing tax on the roadmap, and it is invisible in the original build estimate. Teams that pick Next.js Commerce and stay happy are the ones that budget for it explicitly instead of pretending it will not happen.
Escape hatches and the exit cost
Next.js Commerce is mostly ordinary Next.js, so a team that later wants to swap Shopify for another commerce backend rewrites a data layer rather than a storefront. Hydrogen’s abstractions are Shopify shaped by design, which is exactly why it is productive and exactly why leaving is more expensive.
Worth noting that Shopify has been previewing a framework agnostic direction for Hydrogen, reimagining it as a toolkit of storefront primitives usable from Next.js, SvelteKit, Astro, Nuxt and others. Shopify has been explicit that the API will change and that this is not a migration mandate, so it is a signal about where the platform is heading rather than something to build a 2026 roadmap on. Anyone tracking this should read the release notes at Shopify’s Hydrogen updates page rather than relying on secondhand summaries.
What each stack actually costs to run
Build cost is where most comparisons stop, which is unfortunate, because the run cost over three years usually exceeds it. The table below is a planning framework rather than a quote. Actual figures vary enormously by catalog size, traffic profile and whether the work is in house or agency led, and hosting terms change, so verify current pricing directly with Shopify and Vercel.
| Cost line | Hydrogen on Oxygen | Next.js Commerce on Vercel |
|---|---|---|
| Hosting | Bundled into the Shopify plan | Separate subscription, scales with traffic and function usage |
| Initial build | Lower, primitives are provided | Higher, more is hand written |
| Framework upgrades | Quarterly releases, guided migrations | Next.js major versions plus your own template drift |
| Shopify feature parity | Largely maintained by Shopify | Recurring internal engineering |
| Talent cost | Higher rate, smaller pool | Lower rate, larger pool |
| Observability and support | Single vendor escalation | Two vendors, more instrumentation work |
| Realistic 3 year skew | Cheaper for pure commerce | Cheaper when the site does many jobs |
One number consistently gets left out of these models: the cost of the content layer. Neither framework ships a CMS, and editorial teams will not write product storytelling in JSON files. Budget for that from the start, and read up on headless CMS choices for retail content teams before the frontend decision hardens, because CMS choice constrains the frontend more often than the reverse.
The broader question of whether the headless premium is justified at all deserves its own scrutiny. The analysis in headless versus monolithic Shopify and the real cost difference is the honest starting point, and plenty of teams who work through it conclude that a well built theme plus app extensions gets them 85 percent of the benefit for 25 percent of the cost.
Common mistakes and how to avoid them
The failure patterns in headless projects are remarkably consistent, and almost none of them are framework specific.
Picking the framework before defining the problem
Teams routinely select Hydrogen or Next.js Commerce in week one, then spend months discovering that the actual constraint was a slow PIM, a bloated tag stack or a merchandising workflow nobody wanted to change. Write down the three measurable outcomes the rebuild must deliver before anyone opens an editor. If those outcomes do not require a custom frontend, the rebuild is the wrong project.
Underestimating what the theme was quietly doing
A Shopify theme handles gift cards, discount edge cases, market specific pricing, accessibility defaults, app embeds and a long tail of merchandising features that nobody documents because they simply work. Headless means reimplementing or deliberately dropping each one. Audit the current storefront feature by feature and mark each as rebuild, drop or defer, because the surprises show up in week ten otherwise.
Treating apps as a solved problem
Most Shopify apps inject their functionality into the theme. On a headless storefront that injection point does not exist, so reviews widgets, upsell tools, loyalty programmes and subscription apps need API integrations or replacements. Inventory every installed app early and confirm each one exposes a Storefront API or a headless SDK, because the ones that do not become custom builds.
Skipping the operating model conversation
Headless moves control from merchandisers to engineers unless the team deliberately prevents it. If changing a homepage banner now requires a pull request, marketing velocity collapses and everyone blames the framework. Decide upfront which surfaces are CMS driven and which are code, and staff accordingly.
Assuming SEO carries over automatically
Both frameworks can produce excellent technical SEO, and both can quietly ship a storefront missing structured data, canonical tags, correct pagination or a working sitemap for the whole catalog. Neither template solves this for you at scale. Treat SEO parity as a launch blocker with its own checklist, not a post launch cleanup task.
Examples from US retail and e-commerce
Abstract comparisons only go so far, so here are the three situations where the answer is usually clear, drawn from how US mid market teams actually make the call.
The Shopify first apparel brand. Roughly 4,000 SKUs, heavy seasonal drops, a small in house engineering team of three, and a merchandising team that changes the homepage weekly. Hydrogen wins comfortably. The brand’s differentiator is merchandising speed, not architectural flexibility, and every week Hydrogen saves on cart, accounts and analytics plumbing is a week spent on the drop calendar instead. Brands including Allbirds and Gymshark run production Hydrogen storefronts, which is a useful signal that the framework holds up at that scale.
The media and commerce hybrid. A publisher with a store attached, or a brand where editorial traffic dwarfs product traffic. Next.js Commerce wins, and it is not close. The store is one surface among many, the team is already running Next.js for the content site, and forcing that into a Shopify shaped framework creates friction on every non commerce page. The commerce specific work is genuinely a minority of the codebase here.
The multichannel seller. A retailer running Shopify alongside marketplace channels, where the website is the brand anchor but a meaningful share of revenue arrives through eBay, Amazon or Walmart. The frontend framework matters less than the operational tooling around pricing and inventory sync, and teams in this position get more return from disciplined channel economics, including getting serious about how to price items on eBay without eroding margin, than from either framework. If the team leans Shopify native for everything else, Hydrogen is the lower friction default.
A pattern worth naming: the teams that regret their choice are almost never the ones who picked the “wrong” framework on technical grounds. They are the ones who picked a framework that did not match how their organisation actually works.
A decision framework, plus the tools and vendors worth knowing
You can reach a defensible answer in about a week without building a prototype of each.
Five questions that settle it
- Is commerce more than 70 percent of the site’s purpose? Yes points to Hydrogen. No points to Next.js Commerce.
- Can you hire or retain a Hydrogen capable developer within 60 days? If not, the framework with the deeper talent pool is the safer institutional bet regardless of technical merit.
- How fast must new Shopify features reach production? If the answer is “the same quarter they ship”, the feature lag argument decides it for Hydrogen.
- Who owns the hosting relationship and the on call rotation? One vendor is simpler. Two vendors buy flexibility and cost more attention.
- How likely is a commerce backend change in five years? Genuinely likely means paying the Next.js portability premium is rational. Unlikely means it is insurance nobody claims.
Tools and vendors worth having on the shortlist
On the content side, the usual serious candidates are Contentful, Sanity, Storyblok, Contentstack and Prismic, and all of them integrate with either framework. Pick based on the editorial workflow your team will actually use rather than the developer experience, because the CMS is the tool non engineers touch every day.
For search and merchandising beyond what Shopify provides natively, Algolia, Constructor and Klevu all offer headless ready APIs. For observability, Vercel Analytics or Datadog on the Next.js side, and Shopify’s own analytics plus a third party real user monitoring tool on the Hydrogen side. For the theming layer on Hydrogen specifically, tools such as Weaverse exist to give merchandisers visual control without a deploy.
On the partner side, the meaningful filter is not agency size but whether they have shipped and then operated a headless storefront for at least a year. Ask for a reference from a client who is 18 months post launch, because the launch is the easy part and the second year is where the maintenance model reveals itself. A structured view of the wider vendor landscape is laid out in the 2026 headless commerce stack worth shortlisting, which is a useful cross check against whatever an agency proposes.
Finally, keep the decision reversible where you cheaply can. Isolate the Storefront API data layer behind your own module in either framework, keep business logic out of components, and document the app integrations you replaced. None of that prevents a migration, but it turns a rewrite into a refactor. And if the exercise surfaces doubts about the underlying platform rather than the frontend, step back to the e-commerce platform selection guide before spending a budget cycle on the wrong layer of the stack.
FAQ
Is Hydrogen faster than Next.js Commerce?
Not meaningfully. Both stream server rendered React from an edge network against the same Storefront API, so the gap between two well built implementations is small. Real world performance is dominated by image weight, third party scripts and client side JavaScript volume, all of which are team decisions rather than framework properties.
Do I have to use Oxygen if I choose Hydrogen?
No. Hydrogen runs on Vercel and Cloudflare Workers as well. That said, most production Hydrogen builds use Oxygen because it is the combination Shopify supports end to end, with preview environments tied to the Shopify admin and hosting bundled into the Shopify relationship rather than billed separately.
Is Next.js Commerce a framework or a template?
A template. You clone it, own the code and maintain it yourself, which means no version upgrade path from Vercel for the commerce logic. Hydrogen is a versioned dependency you upgrade on Shopify’s quarterly cadence. This distinction drives most of the long term maintenance difference between the two.
Which one is cheaper over three years?
It depends on what the site does. For pure commerce, Hydrogen usually costs less because the primitives are provided and hosting is bundled. For sites where commerce is one of several jobs, Next.js Commerce usually costs less because the alternative is fighting the framework on every non commerce page. Talent costs can flip either conclusion.
What happens to my Shopify apps on a headless storefront?
Apps that inject into the theme stop working, because that injection point no longer exists. Anything customer facing, including reviews, upsells, loyalty and subscriptions, needs an API integration, a headless SDK or a replacement. Apps that operate purely in the admin, such as inventory or fulfilment tools, are unaffected.
Can I migrate from Next.js Commerce to Hydrogen later, or the reverse?
Both directions are possible and both are real projects rather than weekend refactors. Moving from Next.js Commerce to Hydrogen is usually easier because you gain primitives rather than rebuilding them. Isolating your Storefront API calls behind a single module from day one materially reduces the cost of either move.
Does headless improve SEO compared with a Shopify theme?
Not automatically, and it can hurt if the launch checklist is thin. Both frameworks are capable of excellent technical SEO, but structured data, canonical tags, pagination, hreflang and full catalog sitemaps have to be implemented deliberately. Treat SEO parity with your current storefront as a launch blocker rather than a follow up task.
What is Shopify’s framework agnostic Hydrogen preview, and should I wait for it?
It is a developer preview that reimagines Hydrogen as a toolkit of storefront primitives usable from Next.js, SvelteKit, Astro and others. Shopify has said the API will change, more framework bindings are coming and existing Hydrogen keeps working, so it is a directional signal rather than something to plan a 2026 build around. Check the official release notes for current status.
How big does a store need to be before headless makes sense?
There is no revenue threshold that settles it, but the practical test is whether you have a dedicated frontend engineering capability that will still exist in three years. Without that, the maintenance burden lands on an agency retainer or on nobody. Many mid market retailers get most of the benefit from an optimised theme plus app extensions at a fraction of the cost.