Next.js + Medusa over SAP Com­merce: why I pick the open-source stack

SAP Com­merce + An­gu­lar gets pitched as the en­ter­prise stan­dard, and al­most no­body opens the full bill while do­ing it. The ex­pen­sive part is not the li­cence. It is the qui­et be­lief that "safe" and "SAP" mean the same thing.

We build com­merce stacks our­selves, run them on our own in­fra­struc­ture, and sit in the pitch­es where a CFO even­tu­al­ly wants to see the num­bers. From that seat, "Next.js + Medusa over SAP Com­merce" is not a mat­ter of taste be­tween two frame­works. It is a de­ci­sion about to­tal cost of own­er­ship, ven­dor lock-in, and how many peo­ple will still be able to touch your code in five years. All three are set­tled be­fore the first prod­uct page ever ren­ders.

You can build an ex­cel­lent shop on SAP Com­merce Cloud. That is not the ar­gu­ment. SAP has sat as a Leader in the Gart­ner Mag­ic Quad­rant for Dig­i­tal Com­merce for years run­ning, and any­one claim­ing SAP Com­merce is a bad prod­uct has nev­er ac­tu­al­ly run it.

The point sits else­where. A tech­nol­o­gy de­ci­sion is al­ways also a strate­gic, cul­tur­al and po­lit­i­cal de­ci­sion about pow­er. Choose SAP Com­merce + An­gu­lar and you are not just buy­ing soft­ware. You are buy­ing an op­er­at­ing mod­el, a li­cence path, a cer­ti­fi­ca­tion mar­ket for your ser­vice providers, and a hir­ing mar­ket for your de­vel­op­ers. Those four things shape your cost curve for years, and none of them shows up in an ar­chi­tec­ture di­a­gram.

The ar­chi­tec­ture of SAP Com­merce is it­self part of the ar­gu­ment. At its core, CCv2 is a Java/Spring ap­pli­ca­tion, the for­mer Hy­bris, on em­bed­ded Tom­cat, with the OCC REST API as its in­ter­face. The com­pos­able store­front, Spar­ta­cus, is an An­gu­lar fron­tend that talks ex­clu­sive­ly through that com­merce REST API. So in prac­tice you need Java/Spring com­pe­tence in the back­end and An­gu­lar com­pe­tence in the fron­tend at the same time. That is not a de­tail, that is your staffing plan for the next sev­er­al years.

Start with the li­cence, be­cause it is the most hon­est sig­nal. The of­fi­cial SAP pric­ing page for Com­merce Cloud names no edi­tion or price in­for­ma­tion what­so­ev­er. It points you to "Re­quest a demo" and "Re­quest a quote". That is not a mar­ket­ing over­sight, it is the busi­ness mod­el: a ne­go­ti­a­tion-based, opaque en­ter­prise li­cence.

For a de­ci­sion-mak­er who has to de­fend a TCO case to the board, that is a struc­tur­al prob­lem. You are bud­get­ing against a num­ber you only learn af­ter con­tract ne­go­ti­a­tion, typ­i­cal­ly tied to your gross mer­chan­dise vol­ume, so it ris­es with your suc­cess. The cir­cu­lat­ing es­ti­mates of six- to sev­en-fig­ure an­nu­al sums plus im­ple­men­ta­tion costs come, with­out ex­cep­tion, from SAP part­ners rather than SAP it­self. I de­lib­er­ate­ly treat them not as fact but as what they are: ranges from par­ties with an in­ter­est in the an­swer. That opac­i­ty is it­self part of the bill.

Op­er­a­tions are el­e­gant­ly solved in­side the li­cence mod­el and, at the same time, the heart of the de­pen­den­cy. CCv2 runs as a man­aged PaaS on Mi­crosoft Azure, with Ku­ber­netes and Azure SQL, and SAP runs the build and de­ploy pipelines. Host­ing is in­clud­ed. That sounds con­ve­nient, and it is. You pay for that con­ve­nience by nev­er hold­ing the in­fra­struc­ture your rev­enue runs on in your own hands. Data sov­er­eign­ty and data lo­cal­i­sa­tion stop be­ing set­tings you con­trol and be­come con­tract an­nex­es, and in a third-coun­try trans­fer they quick­ly turn into a NIS2 and GDPR ques­tion you do not own your­self.

Then the agency de­pen­den­cy. SAP runs its own Build/Sell/Ser­vice/Run pro­gramme through Part­nerEdge, and both roll­out and op­er­a­tions run in prac­tice through cer­ti­fied sys­tem in­te­gra­tors. That is a struc­tur­al cost fac­tor: you do not pick from the open mar­ket, you pick from a cer­ti­fied pool. A pro­pri­etary for­mat like Im­pEx, SAP's mod­el-aware im­port/ex­port for­mat that un­der­stands type hi­er­ar­chies and cat­a­logue ver­sions, re­in­forces it. It is tech­ni­cal­ly sen­si­ble and at the same time a data struc­ture that binds your in­sti­tu­tion­al knowl­edge to one ecosys­tem.

Set the oth­er side against that. Medusa is avail­able un­der a gen­uine MIT li­cence, no open-core, no BSL, no li­cence bait-and-switch. The core is ful­ly self-hostable, and Post­greSQL is the pro­duc­tion data­base. On a self-host­ed stack on your own in­fra­struc­ture, and we run ex­act­ly this GDPR-com­pli­ant in Ger­many on Het­zn­er, en­try sits in the low tens of eu­ros per month, while a high-avail­abil­i­ty set­up with re­dun­dant in­stances and a sep­a­rate data­base lands rough­ly in the low hun­dreds of eu­ros per month. A clean ini­tial im­ple­men­ta­tion costs a one-off five-fig­ure sum, and on­go­ing op­er­a­tions take a few hours a month. We ran the same me­chan­ics through in the Het­zn­er in­stead of Ver­cel com­par­i­son.

The de­ci­sive dif­fer­ence is the di­rec­tion of the cost curve. Self-host­ed costs fall over time, be­cause hard­ware gets cheap­er and your team gets more prac­tised. Li­cence and man­aged costs rise with project suc­cess, be­cause they hang off vol­ume, users or GMV. That me­chan­ic of­ten only tips a make-or-buy de­ci­sion in the sec­ond or third year.

The frame­work ques­tion gets waved off as a holy war. It is in fact a hard ques­tion of de­vel­op­er avail­abil­i­ty, and there­fore a FinOps and risk ques­tion.

The num­bers are un­am­bigu­ous. The Stack Over­flow De­vel­op­er Sur­vey 2025 puts Re­act at rough­ly 45 per­cent of all re­spon­dents and An­gu­lar at rough­ly 18 per­cent, so Re­act is used about two and a half times as of­ten. Among pro­fes­sion­al de­vel­op­ers the ra­tio bare­ly shifts. In State of JS 2024 Re­act leads clear­ly, and An­gu­lar was pushed to third place on us­age by Vue. The npm down­load and GitHub fig­ures point the same way, though raw npm num­bers are in­flat­ed by CI pipelines and give you an or­der of mag­ni­tude, not an ex­act adop­tion mea­sure. Sev­er­al in­de­pen­dent sources, the same con­ver­gence: Re­act is car­ried more broad­ly.

What does that mean op­er­a­tional­ly? Bet on An­gu­lar and you re­cruit from a small­er pool, tend to pay more for spe­cial­ists, and are more tight­ly bound to a provider that keeps the skill set on hand. Bet on Re­act/Next.js and you reach the largest fron­tend de­vel­op­er mar­ket in the world: eas­i­er hir­ing, a big­ger free­lancer pool, low­er risk that an agency switch leaves you paral­ysed for months. For a CIO who tracks de­vel­op­er avail­abil­i­ty as a run-the-busi­ness risk, that is not a nice-to-have, it is ven­dor risk man­age­ment.

I want to stay fair, be­cause there is a real strength here. An­gu­lar is opin­ion­at­ed, sta­ble and main­tained for the long term. In large, gov­er­nance-dri­ven or­gan­i­sa­tions that is pre­cise­ly an ad­van­tage: less sprawl, clear con­ven­tions, a frame­work that dic­tates de­ci­sions in­stead of leav­ing them to every team. If you have to keep a 200-strong fron­tend team con­sis­tent over five years, An­gu­lar gives you good rea­sons. That strength is real. It just does not jus­ti­fy every green­field de­ci­sion, where you are start­ing fresh any­way and could take the broad­er mar­ket with you.

So this does not stay an ab­stract sov­er­eign­ty ar­gu­ment: the stack car­ries func­tion­al­ly too. Next.js with Re­act Serv­er Com­po­nents mea­sur­ably cuts the JavaScript shipped to the brows­er, be­cause only com­po­nents ex­plic­it­ly marked as client land in the client bun­dle. Ac­cord­ing to the doc­u­men­ta­tion that im­proves First Con­tent­ful Paint. In­cre­men­tal Sta­t­ic Re­gen­er­a­tion serves pre-ren­dered sta­t­ic pages for most re­quests on a stale-while-reval­i­date ba­sis and low­ers serv­er load, which mat­ters once per­for­mance turns into con­ver­sion.

On self-host­ing the good news is con­crete: the of­fi­cial Next.js self-host­ing docs con­firm that a Node.js serv­er and Dock­er sup­port all fea­tures. next/im­age op­ti­mi­sa­tion runs self-host­ed with no ex­tra con­fig­u­ra­tion, and so does mid­dle­ware. What you lose with­out Ver­cel is not the fea­ture but the glob­al­ly dis­trib­uted edge ex­e­cu­tion. That is an hon­est, small price for most DACH shops whose traf­fic is re­gion­al any­way.

I will not hide the gen­uine­ly hard part: ISR caching only works au­to­mat­i­cal­ly on a sin­gle in­stance with a per­sis­tent disk. The mo­ment you scale across sev­er­al in­stances be­hind a CDN, you need a cus­tom cache han­dler, on Re­dis or S3 for ex­am­ple, plus shared en­cryp­tion keys and sta­ble de­ploy­ment IDs. That is ex­act­ly the val­ue propo­si­tion that makes Ver­cel hard to re­build. It is solv­able, with Coo­lify, Dock­er and a bit of op­er­a­tional dis­ci­pline, but it is op­er­a­tional re­spon­si­bil­i­ty that you del­e­gate to the li­cence with SAP. Any­one re-eval­u­at­ing Medusa and Next.js should first be clear on what Medusa.js ac­tu­al­ly is and which com­merce pro­files it is built for.

Now the hon­est com­pli­ca­tion, with­out which any rec­om­men­da­tion would just be mar­ket­ing.

If your or­gan­i­sa­tion al­ready sits deep in­side an SAP-ERP land­scape, with Medusa you pay for ex­act­ly the in­te­gra­tion work that SAP Com­merce ships. SAP Com­merce is na­tive­ly em­bed­ded in an ex­ist­ing SAP world: in­ven­to­ry, prices, or­ders, cus­tomers. That in­te­gra­tion is real and ex­pen­sive to re­build. With Medusa you build the bridge be­tween shop and ERP your­self, and that is not a week­end project but an in­te­gra­tion project with its own risk pro­file.

Sec­ond, Medusa is younger. The 2.0 GA land­ed in Oc­to­ber 2024, and the jump from v1 to v2 brought break­ing changes and mi­gra­tion ef­fort. More im­por­tant still: for deep B2B process­es the core only ships lim­it­ed build­ing blocks, sales chan­nels, cus­tomer groups, price lists. Fea­tures like com­pa­ny man­age­ment, spend­ing lim­its or quote and ap­proval work­flows come from the of­fi­cial b2b-starter. And that is ex­plic­it­ly boil­er­plate and ref­er­ence code, not a main­tained out-of-the-box prod­uct fea­ture. That dis­tinc­tion is de­ci­sive: you get a start­ing point, not a prod­uct. What­ev­er you build with it, you main­tain your­self.

For high­ly com­plex B2B com­merce process­es with deep ERP in­te­gra­tion, SAP Com­merce can there­fore stay the eco­nom­i­cal­ly cor­rect call. Not be­cause it sounds "safer", but be­cause the sum of bun­dled in­te­gra­tion and ma­ture en­ter­prise mod­ules out­weighs the build-it-your­self ef­fort. That is a rare but real con­stel­la­tion. Any­one who has it should take SAP, with open eyes for the lock-in, not in spite of it. Which com­merce pro­files fit Medusa well and which do not can be worked through clean­ly against con­crete re­quire­ments; we sort­ed that by the ques­tion of whom head­less com­merce with Medusa ac­tu­al­ly suits.

Sep­a­rate two ques­tions that pitch­es sys­tem­at­i­cal­ly blur: "Is SAP Com­merce a good prod­uct?" and "Is SAP Com­merce the right de­ci­sion for us?". The first an­swer is of­ten yes. The sec­ond hangs on your start­ing po­si­tion, not on SAP's Gart­ner place­ment.

Open the full bill be­fore you sign. Li­cence plus re­newals plus im­ple­men­ta­tion plus cer­ti­fied op­er­a­tions plus a tight, ex­pen­sive An­gu­lar-and-Java hir­ing mar­ket, against an MIT-li­censed, Post­greSQL-na­tive, self-hostable stack with the largest fron­tend de­vel­op­er pool in the world. Cal­cu­late over three years, not the first one. And fac­tor in the di­rec­tion of the cost curve, not just the start­ing point.

If you have a green­field project with­out deep SAP-ERP ties, Next.js + Medusa is my de­fault, for strate­gic rea­sons, not tech­ni­cal fash­ion. You buy in­vest­ment se­cu­ri­ty, tech­no­log­i­cal sov­er­eign­ty and de­vel­op­er avail­abil­i­ty in­stead of a con­tract that gets more ex­pen­sive as you suc­ceed. If you sit deep in­side SAP and run high­ly com­plex B2B process­es, SAP stays a de­fen­si­ble choice, as long as you know what you buy along with the con­ve­nience. What you should not do is buy the de­ci­sion as a "safe stan­dard" with­out hav­ing seen the bill. Buy an ar­chi­tec­ture with­out know­ing its to­tal cost, and you buy your ser­vice provider's in­ter­ests right along with it. How a stack like this fits into the wider Next.js pic­ture, we pulled to­geth­er on our Next.js overview.