Shopify Hydrogen vs Next.js Commerce: A Two-Build Postmortem

Last year we shipped two headless storefronts within four months of each other. Same product category (mid-market apparel), similar catalogue size (~4k SKUs), similar traffic profile. One went out on Shopify Hydrogen + Oxygen. The other on Next.js Commerce deployed to Vercel, pulling from the Storefront API. This is what the postmortem actually looked like — not the vendor pitch.

Why we picked different stacks for similar brands

Both clients wanted to move off a Liquid theme that had been bolted onto for years. Both had the same PDP performance complaints and the same merchandising ambitions. So why did we recommend different stacks?

Client A had a lean team: one senior full-stack engineer, no dedicated DevOps. They wanted a Shopify-shaped world — orders, inventory, checkout, all managed. Hydrogen made sense because Shopify hosts it, ships the SDK, and the mental model rarely leaves the Shopify universe.

Client B had three engineers, an existing marketing site on Next.js, a headless CMS (Sanity), and a roadmap that included a subscription product that would eventually need custom checkout logic gated behind Shopify Plus. They wanted one framework across marketing and commerce. Next.js Commerce fit the org, not just the store.

The framework question is almost never about the framework. It's about the team shape and the roadmap two years out.

What Hydrogen got right

Hydrogen 2 (the Remix-based version, not the original React Server Components preview) is genuinely pleasant when your world is Shopify. A few things stood out.

Oxygen removes an entire category of decisions

Oxygen is Shopify's edge hosting for Hydrogen. You push, it deploys, previews are per-branch, and it's included with the Shopify plan. No Vercel invoice, no separate observability stack, no cold-start conversations. For Client A's team of one, that mattered more than any benchmark.

The Storefront API client is opinionated in a good way

Hydrogen's createStorefrontClient handles caching, cache tags, and the Shopify-specific headers you'd otherwise wire by hand. The cache primitives map to Shopify's CDN semantics:

const {product} = await storefront.query(PRODUCT_QUERY, {
  variables: {handle},
  cache: storefront.CacheLong(),
});

That one line replaces a stack of decisions we've had to make on Next: which fetcher, which cache tag strategy, which revalidation trigger. Hydrogen ships a sensible default and you override when you need to.

Cart and checkout handoff just works

Cart lines, discount codes, buyer identity, and the handoff to Shopify's checkout are covered by first-party hooks. We didn't write a single line of cart state management. On a headless build, that's usually two weeks of work and a bug backlog.

What Hydrogen got wrong (for us)

Content modelling outside Shopify is awkward

Client A wanted editorial landing pages — the kind of thing you'd naturally model in Sanity or Contentful. Metaobjects have improved, but if your content team lives in a real CMS, wiring that into Hydrogen means giving up some of the caching ergonomics because you're now juggling two data sources with different invalidation stories.

Oxygen is a walled garden

Great until you need something Oxygen doesn't do. We wanted a small Node service for a personalisation experiment. On Vercel or Fly, trivial. On Oxygen, you're pushed toward Shopify Functions or an external service, which means another deployment target and another set of secrets to rotate.

Debugging server-side rendering in Remix

Remix is fine. But when a loader silently returns partial data because the Storefront API throttled you, the error surface is not obvious. We spent longer than we'd like to admit chasing intermittent PDP blanks that turned out to be rate limits during a bot crawl.

What Next.js Commerce got right

Next.js Commerce is a reference template, not a framework. That's the mental shift. Vercel maintains a Shopify-flavoured version, but it's a starting point you own from day one.

One framework, one deploy target, one mental model

Client B's marketing pages, blog, storefront, and eventually their account area all live in the same Next.js app. Same router, same components, same auth. Shared header/footer/analytics without an iframe or a subdomain hack. For a team that already knows Next, onboarding was measured in days.

Composability with other data sources

Sanity for editorial, Shopify for commerce, Algolia for search, a Postgres for a loyalty ledger — all sit behind Next's data layer without fighting each other. Route segments and fetch cache tags let us invalidate precisely:

export async function getProduct(handle: string) {
  const res = await fetch(SHOPIFY_ENDPOINT, {
    method: 'POST',
    headers: {'X-Shopify-Storefront-Access-Token': token},
    body: JSON.stringify({query: PRODUCT_QUERY, variables: {handle}}),
    next: {tags: [`product:${handle}`], revalidate: 3600},
  });
  return res.json();
}

When a product updates, a Shopify webhook hits an API route and calls revalidateTag. Clean.

Performance ceiling is higher

With aggressive PPR (partial prerendering) and streaming, we hit better LCP on category pages than the Hydrogen build. Not because Hydrogen is slow — it isn't — but because we had more knobs to turn and a team willing to turn them.

What Next.js Commerce got wrong

You own the cart. All of it.

Cart persistence, merging anonymous and authenticated carts, discount code state, checkout handoff — every line of it is your code. The template gives you a starting point but you'll rewrite most of it. Budget two sprints minimum, more if you support multiple currencies or B2B.

Vercel bills scale with success

This is not a Vercel complaint — the pricing is transparent. But a headless storefront on a growth trajectory can produce surprising invoices around function invocations and edge middleware. Model this before you commit. We now include a Vercel cost projection in every Next.js Commerce proposal.

The Storefront API rate limits still exist

You hit the same throttling Hydrogen hits, but without the SDK's opinionated retry and caching. We ended up writing a small wrapper with exponential backoff and a Redis-backed request cache for hot queries. Nothing exotic, but it's work Hydrogen would have saved us.

The scorecard, honestly

Concern	Hydrogen + Oxygen	Next.js Commerce
Time to first deploy	Days	1–2 weeks
Cart & checkout	First-party	You build it
Multi-source content	Awkward	Native
Hosting cost predictability	Included in Shopify	Metered, scales with traffic
Team hiring pool	Smaller	Larger
Escape hatches	Limited	Many
Performance ceiling	High	Higher (with effort)

Neither of these builds regretted their choice. That's the honest answer. Both stores shipped, both improved conversion versus the Liquid baseline (mid-single-digit percentage lifts on PDP-to-cart in our measurements), and both teams are still productive on the stack a year later.

Where we'd start

If you're staring at a headless decision in 2026, ask three questions before you look at a single benchmark.

1. What does your team already ship in? A Next shop building Hydrogen is a team learning Remix, Oxygen, and Shopify's conventions simultaneously. That's a tax.
2. Does your roadmap stay inside Shopify? If yes, Hydrogen removes work. If you're stitching together CMS, search, loyalty, and a marketing site, Next.js Commerce respects that reality.
3. Who owns the cart in year two? If the answer is "nobody wants to", pick Hydrogen. If the answer is "we want full control for a subscription flow we haven't built yet", pick Next.

We still recommend both, and we've built a decision tree we walk clients through before any code gets written. If you want to see how we'd frame it for your catalogue, our e-commerce engineering practice is the place to start.