Medusa vs Magento (Adobe Commerce): a free licence and a paid decision

Choose Magento Open Source or Adobe Commerce if you need a mature merchandising admin out of the box, a wide extension catalogue and a supplier you can hire in almost any market. Choose Medusa if your selling logic has to live in your own TypeScript rather than in the configuration of somebody else’s PHP monolith, and you have people to maintain it.

This comparison nearly always opens on the wrong question. Someone asks what the licence costs, the answer for Magento Open Source is nothing, and the conversation ends before it starts. On both sides the licence is the smallest line on the invoice.

So we split it into three bills: licence, build, and whatever happens after launch.

The licence is free, the build is not

Magento Open Source ships under the Open Software License 3.0. The magento/magento2 repository puts it plainly: every source file in the distribution is licensed under OSL 3.0 or the terms of the applicable ordering document. The Medusa core ships under MIT, with separate terms for its Enterprise edition. Neither side charges for the engine and neither takes a share of revenue.

The next line on the bill reads differently. Magento agencies in Poland publish their ranges, and the figures surprise anyone who arrived expecting the free-versus-expensive story. Smartbees quotes 80,000 to 150,000 PLN net for a B2C build on an off-the-shelf theme on Open Source, 150,000 to 300,000 PLN and above for a dedicated B2B platform, and 400,000 PLN and above at enterprise scope. Advox works from higher budget brackets still: 200,000 PLN, 500,000 PLN and a million, at developer rates of 200 to 250 PLN net an hour.

Two caveats belong with those numbers. They come from two different suppliers describing different scopes, so treat them as a band rather than a like-for-like comparison. And neither of them is the platform vendor. Both are agencies that build on Magento, so their price lists describe a market, not a product.

Net of tax. The Magento ranges come from two Magento agencies in the Polish market and describe a market rather than a vendor price list: Smartbees (updated 14 May 2026) and Advox Studio (20 January 2026). The Medusa ranges are ours and we publish them in full, in Polish złoty, converted here at the NBP mid rate of 4.3228 PLN to 1 EUR from 11 September 2026. Adobe and Medusa data checked at source on 12 September 2026. We revisit this table quarterly.

We publish our own ranges because nobody in the Medusa market does. On the Magento side the reverse is true, which is exactly why a market band can be assembled at all. Our pricing model sits on the pricing page, and the full three-year arithmetic in our piece on the true cost of owning your platform.

Adobe Commerce has a price you cannot look up

Adobe does not publish an Adobe Commerce price list, and says so in its own documentation. The limits page for Adobe Commerce Optimizer states that the base allocation is determined by GMV tier, meaning the value of sales passing through the platform. The thresholds themselves are absent from that page. For those, Adobe points you to an account representative or to support.

Figures in the tens of thousands of dollars a year circulate widely. They come from integrators and platform comparison sites, so treat them as market rumour about the right order of magnitude rather than as an offer. One Magento agency in Poland puts 30,000 to 50,000 USD a year in writing and adds that the price climbs with revenue. Adobe neither confirms nor denies any of it, because Adobe simply does not say.

The practical consequence is singular: no Adobe Commerce budget exists before a call with Adobe sales.

B2B sits behind the paid licence

Here is the most consequential fact in the whole comparison, and most write-ups skip it. The B2B capabilities wholesalers look at Magento for are no part of Magento Open Source. Adobe ships them as the Adobe Commerce B2B extension and its documentation states in plain terms that the extension is available for Adobe Commerce only and requires a separate licence.

Behind that licence boundary sits precisely the set every wholesale project asks about:

• Company accounts: organisational structure, multiple buyers, roles and purchasing permissions under one account.
• Shared catalogues: a gated assortment with customer-specific pricing.
• Negotiable quotes: an enquiry, offer and approval path instead of an ordinary cart.
• Requisition lists and quick order: repeat purchasing without clicking through the catalogue.
• Purchase orders: an approval flow and spend control on the buyer’s side.

On Magento Open Source that leaves two routes: buy a third-party B2B extension, or write the logic yourself in PHP. Both end up at the thing that was supposed to count against Medusa, namely your own code to maintain. Medusa gives you customer groups and price lists in the core, ships an official B2B starter, and the remaining commercial rules are written as workflows. The difference comes down to which language the code is in and whose foundation it sits on.

What that scope looks like in practice is set out on B2B eCommerce and in our piece on integrating a B2B store with an ERP. In projects like these the ERP sets the pace, and the storefront is the smallest problem on the list.

Six services to keep running, or two

Magento is a PHP monolith with a long list of infrastructure dependencies. Medusa is a Node.js application with one database. That reads like a technical footnote until somebody starts paying to keep both of them alive.

Magento 2.4.9 requirements per Adobe’s system requirements page (updated 11 August 2026); Medusa requirements per the Medusa installation documentation. Both columns checked on 12 September 2026. MySQL 8.0 reached end of support on 30 April 2026 and Elasticsearch 7.17 on 15 January 2026, so older installations are already on a clock.

That list has two consequences, both visible in a budget. The first is hosting: a stack that needs OpenSearch, RabbitMQ and Valkey costs more to run than an application with a single database, which is why Polish agencies quote Magento hosting from roughly 1,500 PLN a month. The second is the version treadmill. Adobe raises required component versions every year, so maintaining Magento means lifting the whole stack on a cycle, and not only the application on top of it.

September 2026, as evidence rather than a scare

Days before this piece went out, the Magento ecosystem went through an event that describes the real cost of ownership better than any table can. CVE-2026-75650, named StyleSmuggler by the researchers who found it, is unauthenticated remote code execution rated CVSS 10.0, covering Magento Open Source, Adobe Commerce and Adobe Commerce B2B in versions 2.4.4 through 2.4.9. Sansec dates the start of active exploitation to 4 September 2026 and the Adobe hotfix to 7 September.

Those three days say more about the architecture of responsibility than any vendor statement. Adobe ships one full patch bundle a year, in May, and publishes isolated security patches outside that schedule when they are needed. Everything below the vendor line, meaning the patch reaching your production in hours rather than weeks, stays with you.

Now the honest other half, without which this section would be a smear. Medusa has no published security advisories on its GitHub repository at all, which sounds excellent and means very little. Magento has been trading for well over a decade, has an entire security research industry built around it and is a target worth attacking. Medusa is younger, smaller and nobody scans it at that scale. An empty advisory list measures researcher attention first and code quality a distant second.

Selling logic written as code

Medusa is a commerce backend in TypeScript: API routes, workflows holding the business logic, domain modules and PostgreSQL underneath. Payment, fulfilment, CMS and search providers swap out as modules without forking the core. Three consequences for a store:

• A data model shaped around your assortment. Made-to-measure goods, bundles and parameter-driven pricing do not have to end up in description fields or in a spreadsheet alongside.
• Commercial rules as code. Contract pricing, credit limits and order approvals are written as workflows instead of assembled from three extensions by three authors.
• One boundary for many channels. Store, app, wholesale and integrations all travel through the same API, so the source of truth stays singular.

The bill for that deserves stating plainly, or this piece would be a leaflet. Buying Medusa means buying a staffing requirement: TypeScript, PostgreSQL, DevOps, and integrations nobody has written for you. Regional payment gateways and parcel-locker carriers are absent from the official Medusa documentation, so they enter the build scope as engineering work. On Magento they arrive as an extension, and that is a genuine advantage worth pricing before the decision rather than after it.

When Magento or Adobe Commerce wins

This section is not a courtesy. We build on Medusa and will still say Magento is the better answer in several situations, because that is where the arithmetic lands rather than where our preferences do.

• You already run Magento and it works. If the list of grievances comes down to slow hosting and twenty extensions accumulated over the years without review, that is an argument for a cleanup rather than for a platform change.
• You need a mature admin out of the box. Merchandising, multi-store, tax, CMS and content staging have been in Magento for years. Medusa gives you an admin, not a finished merchandising suite.
• Supplier availability matters most. The Magento market is wide, and in ours transparent enough that agencies publish price ranges on their own websites. On the Medusa side that transparency does not exist.
• You are already inside the Adobe stack. If you run AEM, Analytics or Experience Platform, the integration story around Adobe Commerce is an advantage we cannot reproduce with an integration project on a sensible budget.
• You want open source without Adobe. Mage-OS, a community-governed distribution built on Magento 2.4.9, ships its own releases and offers a path independent of Adobe’s commercial priorities.

One more, even though it works against us. If what you need is a standard B2C store and you need it quickly, Magento is no cheap route either, and the ranges above show why. In that case WooCommerce or Shopify is often the sounder call, and we say so out loud.

Moving off Magento without stopping sales

The most common reason anyone reads a piece like this is a Magento installation that has stopped keeping up: a version past its support date, an extension list nobody wants to touch, and a scope of work that grows with every upgrade. The signals that a store has genuinely outgrown its platform are collected in our piece on outgrowing a platform, and the mechanics of moving without a trading gap in migration without stopping sales.

Start with your version’s support end date

Before any migration project begins, check one date. Adobe puts the end of regular support at 31 May 2027 for 2.4.7, 31 May 2028 for 2.4.8 and 31 May 2029 for 2.4.9. If you are still on 2.4.6, regular support ended on 11 August 2026 and extended support runs out on 31 August 2027. That date frames the decision window better than any architectural argument.

Then look at the storefront, where Adobe is changing the terms

Adobe’s newer storefront tooling, the drop-in components built on Edge Delivery Services, requires either an Adobe Commerce as a Cloud Service licence or an Adobe Commerce Optimizer licence, and the documentation adds that drop-ins are unavailable for other deployment types. For a Magento Open Source store that means Adobe’s modern frontend path is gated by licence. A different one stays open: Hyvä, a widely used Magento frontend theme, is fully open source and free according to its own licence page.

Limits of this comparison

Stated plainly, so the piece can be used as a source:

• Performance under load. We benchmarked neither platform and we do not repeat other people’s numbers.
• The Adobe Commerce price. Not published. We give no estimate, because Adobe publishes neither the GMV thresholds nor the rates attached to them.
• A quote for your project. The Magento column is a band from two Polish agencies and the Medusa column is our own published range. Neither is an offer.
• What other Medusa suppliers charge. We publish ours because nobody else in this market publishes theirs. Collecting proposals? Compare the scopes before the totals.
• Markets outside Poland. Hourly rates move a build price further than the engine choice does, so read the figures above as our market and reprice them for yours.
• Anything after publication. Requirements, support dates and the vulnerability details were checked on 12 September 2026. We return to them quarterly.

How to decide without guessing

The sequence that saves the most money is a dull one, and it fits into four questions:

• What is impossible today? Write down everything your current platform cannot do that sits on the plan for the next eighteen months.
• What does standing still cost? A year of running what you already have: hosting, extensions, and the hours spent on upgrades and workarounds.
• Do you need B2B features? If so, price them on both sides as either engineering work or a licence, because Magento Open Source has none of them in the core.
• Who maintains this in two years? That answer outweighs the entire table above, and it does so on both sides.

Where we come into it

Medusa is our foundation rather than our identity. What we build on it we call BEAM: one place a client runs their whole eCommerce from, delivered in stages, from Blueprint through Engineering to Maintenance & Growth. Builds start at 60,000 PLN net and typically land between 80,000 and 200,000 PLN, AI automation is scoped per workflow from 6,000 PLN, and ongoing care starts at 3,500 PLN a month. The scope of the work is set out on Medusa development.

The honest caveat: if the arithmetic lands on Magento or Adobe Commerce, we will say so rather than sell a build that will not pay for itself. And where the bottleneck turns out to be sales channels rather than the platform, Amazon and Allegro account work is run by our sister brand Amazonway.

Both platforms leave the code and the data on your side, and both send the invoice somewhere else. On Magento you pay in running six services from the table above, in an annual upgrade rhythm, and in a licence for B2B features if you need them. On Medusa you pay in the build and in the people, and in return your selling logic lives in code that belongs to you. The decision comes down to which of those invoices you would rather receive for the next three years.