Medusa.js vs Magento 2: Which to Choose and When

Platform selection usually starts from the wrong end. Feature lists are compared, analyst rankings are read, and arguments are had over which technology is newer. The real decision depends on one question: how much of how your customers buy is already in the platform, and how much will you have to write yourself?

This is not a matter of opinion. It can be counted.

Write down: how your customers actually buy. Who places the order, at what price, with whose approval, and against which document. Every line in that list is either a ready-made feature on one platform or custom work on the other. Once the information is written down and available, the rest of the decision becomes simple.

Two choices in our custom development toolbox

Magento 2 is a full-featured e-commerce platform. It includes product management, checkout, customer accounts, and administration. The free version is called Magento Open Source, the commercial package Adobe Commerce. For wholesale, there is a separate module that provides company accounts, price lists, quotes, and approval workflows. This module runs only on Adobe Commerce and requires a separate license; it is not available in the free version. The distinction matters, because this module is Magento's strongest argument for a wholesaler.

Medusa.js is an open-source e-commerce system. Installation provides the backend and admin interface, but the storefront is a separate application hosted independently from the backend. An official Next.js storefront is available as a starting point, and for wholesale there is a separate starter package.

It is a mistake to think of these as opposites: a mature monolith on one side, a modern composable architecture on the other. MACH Alliance describes the second, Gartner still measures the first. Adobe announces that Adobe Commerce was named a Leader for the ninth consecutive year in the 2025 comparison; Gartner rates the paid Adobe Commerce, not the free Magento.

Neither of them tells you which platform suits your shop.

Three questions that decide the outcome

Coverage. How much of your purchasing process is already in the box?

Ownership. Whose code is it, and who maintains and develops it after the project is complete?

Cost. Are you paying for a license or for development?

A fourth possible question (whether an AI agent can buy from your catalogue) is still emerging, and will be addressed separately.

These two also tend to be compared by flexibility. That is the wrong axis. Magento is one of the most flexible platforms in existence: events, plugins, custom modules, and full access to the code. Almost everything can be changed.

The difference is not whether you can change things, but what changing costs. Magento's flexibility works on its own assumptions. If your purchasing process fits what Magento's cart, customer, and wholesale modules already assume, you get a thousand lines of ready-made logic included with the storefront setup.

Medusa's core makes fewer assumptions, giving us freer hands in development, though it does not compromise on capability (Medusa's core has been tested with large catalogues).

The question is therefore not which is more flexible, but whose assumptions your purchasing process fits better.

Coverage: how much is already there

The difference between Magento and Medusa wholesale capabilities

The common view is that Medusa suits retail and serious wholesale means Magento. The comparison says otherwise: the official Medusa wholesale starter package covers most of the same steps. The documentation does direct you to write your own module for company accounts, but the starter package has already done that work.

This covers standard wholesale, but yours is not only standard. Nearly every company has lines in their purchasing process that neither list includes, because they come from their own business model, not from general wholesale practice. Those lines cannot be put in a comparison, because every company has different ones. That is exactly where the decision is truly made: not between which list is longer, but between which platform it is easier to add your specific approach on top of.

What Magento coverage actually means

Adobe's wholesale module describes an organisation that buys.

A company account puts the same company's buyers under one account, where an administrator builds departments, roles, and permissions. The hierarchy itself is designed for approval: buyer adds to cart, manager approves. A shared catalog means different companies see different products and different prices. The catalog is attached to the account, not a filter on the shop page. Quotes happen inside the shop with line items, quantities, and statuses, not as a PDF sent by email. Quick order takes in a list of product codes or a file.

In addition, what Magento covers is a commercial ecosystem. The Adobe Commerce Marketplace has thousands of extensions and templates, and in Estonia you can find Magento developers and predictable hourly rates more easily than Medusa ones. This is Magento's most enduring advantage: when you need a ready-made piece that someone else maintains, it is more likely to exist on the Magento side and less likely on the Medusa side.

What Medusa coverage actually means

The starter package describes the same world. A company can be created and employees invited, each employee can be given a role and spending limit along with how often the limit resets. Approval can be required from both the buyer's company and the seller's side. Quotes happen with messaging between buyer and seller, an order can be modified after submission, and multiple variants can be added to the cart at once.

Since the code is yours, you can redefine what "company/organisation" means: tie it to a contract, a license, a certificate, or whatever object your pricing actually hangs on.

The other thing the Medusa side gives you is independence and momentum. The MIT license means no price negotiations, no revenue-based fees, no license audits. By developer attention, Medusa is clearly ahead: on GitHub, Medusa has 34.3 thousand stars and Magento has 12.1 thousand (August 2026), and the core is evolving at a rapid pace. You generally recruit developers from the TypeScript and React market, where there are more candidates, though specifically Medusa-experienced candidates are fewer.

It can be said plainly that Medusa is weak exactly where Magento is strong. There is essentially no market for ready-made commercial modules: what you buy on the Adobe side, you typically write on the Medusa side. Developer interest and the module market are two different things, and the first does not replace the second.

Ownership: whose code is it and who maintains it

Adobe's wholesale module is a licensed product. Adobe fixes bugs, Adobe updates, and you receive the fix with a version upgrade. You do not maintain that code. Except for custom extensions, which Adobe does not maintain or support, so on update you still need a developer to step in.

Medusa's starter package is a template. You copy it into your own codebase and from that moment it is your code. You update it when Medusa changes, and Medusa development moves at a fast pace. You carry the risk if you do not update, but this is a risk shared with the development community.

The feature list is almost the same. The obligation that begins when the project is complete is completely different. If you do not make this distinction, you buy a finished product in one case and a starting position in the other, thinking you bought the same thing both times.

Both sides have their price.

On the Magento side, every upgrade is a project. Adobe's lifecycle policy gives the dates: 2.4.7 standard support ends May 31, 2027, 2.4.8 on May 31, 2028, and 2.4.9 on May 31, 2029. Extended support for 2.4.7 runs until May 31, 2028, but that is paid breathing room, not a solution. The more custom solutions are written into the platform, the more expensive each upgrade becomes: every "small exception" is code that someone has to replay at every version change.

On the Medusa side, the project is younger. Breaking changes occur, and all the logic you wrote remains yours to maintain. No one sends you a bill for that, which does not mean there is no cost.

One more thing that older comparisons miss. Magento can also be built so that the storefront is separate and fetches data from the backend, this is documented, it is just not the default choice in a standard installation. Adobe itself is moving toward headless: Adobe Commerce as a Cloud Service is built on interfaces, and Commerce Optimizer puts a storefront and catalog service in front of an existing backend. So the claim that Magento is monolithic and Medusa is headless is no longer the whole truth in 2026. For Magento headless choice, Zaproo has a ready product to offer, so your Magento storefront can also be made fast, secure, and tailored to your purchasing process with less effort.

Cost: what you pay for

Adobe does not publish a price list: pricing depends on revenue and starts in the tens of thousands of euros per year. Medusa's license costs zero, but writing the purchasing process and subsequent maintenance is your development bill, plus hosting and DevOps: servers, updates, monitoring.

The question is not which is cheaper, because that depends on how much of your purchasing process fits inside the license. The question is which cost suits you better: an annual license payment or a one-time development bill with an ongoing maintenance obligation.

Case study: revimit.com

So far the discussion has been about what is in the boxes. So that our talk would not be theoretical, we built a real working business on Medusa that is capable enough to carry entrepreneurs in their business long-term. One example of what happens when your purchasing process is not in either box.

REVIMIT Energy Labs OÜ is an Estonian manufacturer whose shop is at www.revimit.com. Previously the company sold on WooCommerce: one country at a time, invoices by hand, wholesale by email. The manufacturer wanted to sell worldwide, serve bulk buyers without human intervention, and be readable by purchasing agents. Zaproo launched the new shop in June 2026: storefront, backend, and content management are separate, the backend is Medusa, content and contract-based logic live in Payload, and the storefront is a custom Next.js shop.

Three key differences can be highlighted that distinguish Revimit from conventional B2B commerce:

Price is unlocked by a signed contract, not by an account. Creating an account does not unlock anything yet. The buyer fills in company details, the VAT number is verified against the European registry, the contract text comes from the content management system and is signed inside the shop. The database retains evidence of which contract version was shown when. The wholesale price is only unlocked by administrator approval, and a cancelled contract closes it in the same step. With a Magento company account, the company can build its structure after account approval. Here the object of approval is a document, not an account, and in code this is a completely different data model.

Discount is calculated across all cart units. Across lines and variants, not by line total. Retail and wholesale tiers work by different logic, and a tier excludes certain shipping discounts: the wholesale price and free shipping do not coexist. Both platforms know cart rules. Neither box includes this combination, where a unit-based tier switches off another discount and simultaneously depends on contract status.

Payment method is locked to the contract. Invoice ordering is available only to a logged-in bulk buyer with a valid signed contract, and the check happens on the server at checkout time, not in the user interface. In Magento's wholesale module, the payment term and credit limit are properties of the company account. Here they belong to the signed document, so cancelling the contract closes the payment method itself, without anyone needing to touch the account.

In addition, orders can be placed to any country in the world, and the EU VAT regime is selected by the server based on the shipping address, not the account profile: destination country rate, export at zero rate, or reverse charge with a valid VAT number. Shipping boundaries, parcel locker selection, and customs data come from the backend. The invoice goes to accounting in one step and carries the same number in both systems.

What this case study proves and what it does not. It does not prove that Medusa is a better platform. If those three rules were written into Magento, what remains is Magento's coverage plus the same work. If written into Medusa, what remains is the backend plus the same work. The choice was which platform to build this work on. The choice was not whether the work would come.

The reverse pattern is exactly as true. An Estonian wholesaler whose catalogue is large, customers buy at contract prices, and orders come in by SKU, describes a purchasing process that is already largely covered by Adobe's wholesale module. Company accounts, departments, approval, shared catalog, and quick order cover most of that list, and the remainder is integration with warehouse software. For such a customer, building the same thing from the Medusa template would be possible but takes its time.

The magical fourth question: can the buyer be an AI

In the AI world, there are 3 main methods in the form of protocols to answer this question, written from different angles by three major players in the IT world.

Model Context Protocol solves the simplest part: how a model sees your system's data and tools.

Agentic Commerce Protocol, maintained by OpenAI and Stripe, describes the purchase itself. The specification is in beta and versions are dated; at the time of writing, the latest is April 17, 2026. It requires three things from the merchant: a machine-readable product feed, a checkout accessible as an interface, and a separate endpoint for delegated payments. The merchant remains the seller; the agent does not take their place.

Agent Payments Protocol comes from Google with more than sixty partners, including Mastercard, PayPal, American Express, Adyen, and Worldpay. AP2 asks the most important question for wholesale: how does the merchant prove that there was genuine authorisation behind the agent's order. The answer is cryptographically signed mandates. An intent mandate carries the buyer's original instruction with limits, a cart mandate fixes the specific line items and total. Together they form an evidence chain that links the buyer's instruction to a specific payment so that it cannot be disputed afterwards.

None of these is a ready-made feature in Magento or Medusa today, and building a product on a beta-stage standard is not sensible.

This affects platform choice indirectly. Magento's GraphQL interface makes the catalogue and checkout accessible to machines already today, so the raw material exists. With Medusa, the storefront is already a separate application that fetches data from the backend, so adding the next consumer is less work than the first separation was. Mandate verification you write yourself in both cases. The difference is in the starting position, not the end result.

Five questions before choosing a platform

The questions follow the same three themes. Answer them before anyone names a platform: the answers are your brief, regardless of which platform you choose.

• Coverage. Look at the list you wrote in the introduction. If most lines are company account, roles, contract pricing, quotes, approval, and SKU-based ordering, Adobe's wholesale module is a ready product for you. If most lines are exceptions, a ready list does not help on either side.

• Coverage. Where does the correct data live? If price, credit, stock, and invoice come from accounting or warehouse software, the shop is only a shop, not the entire company's business logic. The question is how much logic may be left in the shop.

• Ownership. Who maintains your customisations when the project is complete? With Magento, it is a custom solution inside the platform that you replay with every upgrade. Adobe support covers only their own modules, not your custom extensions that may extend them. With Medusa, the code is yours from the start. In both cases it is work, but the bill comes at different times and in different forms.

• Ownership. What do you already have? A working Magento catalogue, extensions, and people with Magento skills are real assets. Starting from scratch with a modern web team is also real work, as is migrating from an existing platform to a new one.

• Cost. Does your purchasing process fit inside the license? If it fits, the license is cheap. If half of it remains custom development, you pay twice.

When to choose which

Choose Magento 2 if the lines in your purchasing process are largely those that the Adobe module already covers. The correct number comes from accounting or warehouse, your people know Magento administration, and you pay for the license precisely so that you do not have to maintain that part yourself.

Choose Medusa.js if your purchasing process has more exceptions than standard. The storefront is your face, the purchasing process is your distinction, and you accept that the code remains yours along with its maintenance.

Do not choose Medusa because Magento seems old, nor Magento because someone said "large enterprise." Gartner's leadership position does not build your approval rule, and modern architecture does not add a requisition list to your shop.

The wrong choice costs the same both ways. A standard wholesaler who starts rebuilding the Adobe module from the Medusa starter package wastes a year. An exception-driven manufacturer who drags the Adobe wholesale module in for a company structure they do not have wastes just as much.

Zaproo builds both. If you want to know before deciding how much of your purchasing process is in the box and how much needs to be built, a 30-minute conversation is enough. Without sales talk.