Disadvantages of Medusa JS: What v2 Fixed and What Didn’t

Last updated: 12 October 2026

Most articles listing the disadvantages of Medusa JS were written against version 1, and most of them now describe a platform that no longer exists. Medusa 2.0 was a ground-up rework, not a point release. Some of the old complaints genuinely went away. Others did not disappear: they changed shape, which is harder to plan for than a limitation that simply stays put. This review is for technical leads and founders weighing Medusa for a new build, and for teams on v1 deciding whether to migrate.

We build on Medusa. That is the bias to know about while reading this. It is also the reason this list is specific rather than diplomatic. The disadvantages of Medusa.js below are the ones that cost real time on real projects, and every one of them is manageable if you see it coming. The expensive version is meeting them in week nine.

The short version first: here is which disadvantages of Medusa.js version 2 actually resolved, and which it carried forward.

What people complained about in v1	Where it stands in v2
Customisation meant patching core services	Fixed. Modules and workflows replace service extension, and the result is far more maintainable
Steep JavaScript and TypeScript requirement	Unchanged, and now joined by an architectural learning curve
Thin plugin ecosystem	Partly worse. Several v1 plugins were deprecated in the transition
Production needs more than one server	Unchanged. Postgres, Redis, and split server and worker processes
Documentation trails the code	Unchanged, and v1 pages still rank in Google
No bundled support guarantee	Unchanged. Accountability is arranged, not bought

1. The learning curve moved rather than shrank

Of all the disadvantages of Medusa.js, this is the one people most often assume version 2 removed. The most common thing said about v1 was that it demanded strong JavaScript and TypeScript people. Still true. But v2 added something v1 did not ask for: architectural literacy.

Core commerce logic in v2 is split into decoupled commerce modules, such as cart, product, order and payment, with no cross-dependencies at the database level, and that pattern makes more sense once you see Medusa’s headless architecture, where the backend and frontend are separate concerns. Business logic that spans modules is written as workflows: sequences of steps with automatic rollback if a step fails. It is a genuinely better model. It is also a model your team has to understand before they can be productive, and it does not resemble how most ecommerce codebases are organised.

There is a specific trap that comes with this. In v1, teams customised Medusa by extending core services. That pattern is gone. If someone on your team learned Medusa two years ago, a meaningful part of what they know is now actively misleading rather than merely outdated.

Worse, the internet has not caught up. The v1 documentation URLs still resolve, and Google still ranks them. Developers routinely land on a v1 page, copy a snippet, and lose an afternoon to an API that no longer exists. It is a small thing that produces a steady drip of wasted hours on every new project.

How to reduce it: start from the official v2 starters and current docs, and treat any tutorial written before late 2024 as unreliable. Check every documentation URL for /v1/ before copying from it. Scope the first build to standard flows and save customisation for after the team has shipped something.

2. Production needs a real stack, not a server

Among the disadvantages of Medusa.js, this is the one most often understated, and the one that surprises teams coming from SaaS. A production Medusa deployment needs:

• PostgreSQL. Version 12 minimum, 14 or higher recommended.
• Redis. Not optional in production. It backs the workflow engine, the event bus, the cache, and distributed locking.
• Two processes, not one. A server process handling HTTP requests from the Medusa storefront and admin, and a worker process handling background jobs, scheduled tasks, and event subscribers such as order confirmation emails. Medusa documents this split explicitly: they are configured through MEDUSA_WORKER_MODE and share the same database and Redis.

Compare that to a SaaS platform where the equivalent decision is choosing a plan, and you have the honest shape of the trade. None of it is exotic infrastructure, but all of it is infrastructure somebody now owns.

The classic failure here is subtle. Medusa ships with an in-memory workflow engine by default, and Medusa recommends the Redis-backed workflow engine in production instead. Deploy the default and everything appears to work, until a process restarts mid-workflow and in-flight operations vanish, or until load exposes that background jobs and web requests are competing for the same process. This is the single most common source of “Medusa is slow” that turns out not to be Medusa at all.

How to reduce it: use the Redis-backed workflow engine in production, split server and worker into separate processes from the first deployment rather than retrofitting, size Postgres deliberately, and load-test the flows you actually run rather than the ones in the demo.

3. You inherit the edges the documentation does not cover

Medusa v2 is young and moving fast, which shapes several of the disadvantages of Medusa.js that remain. That combination produces one of the least visible disadvantages of Medusa.js: the documented path works well, and the undocumented edges are where days disappear. These are not hypothetical.

Payment status that did not advance. A developer running a live Medusa v2 shop documented a period where Stripe charged the card and fired its webhook while the order paid total stayed at zero and its payment status never moved past pending. Because order confirmation emails are typically gated on a completed order, customers paid and then heard nothing. Every order had to be marked paid by hand in the admin. The upstream fixes landed in v2.11.1.

Related issues sit in the tracker under #11766, where a captured payment left the paid total at zero, and #13301, where the core Stripe integration called the capture endpoint twice. Both are now closed.

A shipping rule that evaluated a price as a year. The same write-up documents a comparator in the fulfilment module that ran cart values through Date.parse before comparing them. A bare “60” parses as a date in 1960 and “100” as the year 100 AD, so a 100 pound cart compared against a 60 pound threshold produced the wrong answer and silently stripped the free shipping option. The fix was formatting both values as decimals. Finding it meant reading compiled module code.

Two workflows where you would expect one. In the same write-up: shipping options are evaluated by two separate workflows, one when the storefront lists options and another when the customer actually selects one. Hook only the first and the option displays correctly, then fails on selection with a generic 400 and nothing useful in the logs.

The pattern across all three is the same, and it is the real point: every one had a simple fix, and none of the fixes were obvious. That gap, between a problem being small and a problem being findable, is what a young framework charges you, and it is paid in senior engineering hours rather than licence fees.

How to reduce it: treat the framework GitHub issues as part of your documentation, search them before assuming your own code is at fault, and pin your Medusa version deliberately rather than tracking latest.

4. Upgrades need a budget line, not just a calendar reminder

Two distinct risks live here, and together they are among the disadvantages of Medusa.js that cost most when discovered late. The first is that upgrades occasionally break. Teams have reported production build failures moving between adjacent patch versions, and a version that would not start in production at all. Neither is common, but “we will upgrade when we get a moment” is not a plan for a platform releasing this frequently.

The second is more interesting, and it catches good teams rather than careless ones. When you write a workaround for an upstream bug, that workaround becomes a liability the moment upstream fixes it.

The developer above patched the payment-status bug with a subscriber that captured payments directly. It worked. Then v2.11.1 fixed the bug upstream, the subscriber kept running, and the duplicate action re-triggered order events, sending every customer two confirmation emails. It went unnoticed for months.

How to reduce it: give every workaround an expiry date. In practice that means three things in the code: a comment linking the upstream issue, a flag that lets the workaround be switched off without deleting it, and a note to re-check on the next upgrade of that dependency. Budget upgrade work as recurring maintenance, a percentage of build cost annually, rather than treating it as an unplanned interruption.

5. The integration tail is yours to build

This is one of the disadvantages of Medusa.js that planning can remove entirely, and that a launch sprint cannot. Medusa covers the mainstream well: Stripe is a built-in module provider rather than a third-party plugin now, and the common integrations are in reasonable shape.

The difficulty is the long tail of third-party services. Several v1 plugins were deprecated in the v2 transition, some absorbed into core as module providers and some simply left behind. And if your business depends on something regional, such as a local payment method, a domestic logistics provider, or a tax or e-invoicing regime specific to your market, the realistic assumption is that you are building and maintaining that integration yourself, as a custom module.

On a mainstream SaaS platform, that same integration is frequently a listing in an app store. That difference is a genuine cost, it lands hardest on teams selling into markets outside the US and Western Europe, and it is best discovered during planning rather than during a launch sprint.

How to reduce it: list every must-have integration before committing, check each one against the current Medusa module providers and integrations directory rather than against v1-era blog posts, and price the custom module work for anything that is not there.

6. Accountability is something you arrange, not something you buy

Support is rarely listed among the disadvantages of Medusa.js, which is exactly why it catches teams out. The Medusa community is active and the documentation has improved substantially. But community support has a shape worth naming honestly: fast and generous for common problems, unreliable for deadlines. Nobody in a Discord channel has an obligation to answer you at 2am during a sale.

This is a real difference from a SaaS platform, where a support contract with response times is part of what the subscription buys. With Medusa, that accountability does not come bundled. It has to be arranged deliberately, either through the Medusa commercial offering or through an engineering partner with production Medusa experience.

How to reduce it: decide who is accountable for incidents before launch, name them, and make sure they have access to the infrastructure. “The community” is not an on-call rotation.

7. The admin dashboard is built for operators, and stops there

The Medusa admin is a functional admin panel for the team running the store: product management, order management, inventory and fulfilment. That is what it is for, and judging it as a merchandising or content experience misses the point. The admin only becomes one of the disadvantages of Medusa.js when a team expects it to do more.

But two things genuinely are not included, and both are frequently assumed to be. There is no page builder or editorial layer, so marketing content, landing pages, and long-form product storytelling need either a separate CMS or custom fields in the commerce data.

And if you are building a marketplace, a vendor-facing dashboard where sellers manage their own products, orders and payouts is a separate application with its own authentication, design and maintenance. In marketplace budgets, that is routinely the most underestimated line item.

How to reduce it: decide early whether editors need their own system, and scope vendor tooling as its own workstream with its own timeline rather than as “some admin screens”.

8. The cost does not disappear, it changes category

Cost is the last of the disadvantages of Medusa.js, and the most misread. The honest framing is not cheap versus expensive. It is predictable versus variable.

A SaaS commerce platform bundles hosting, security patches, support and upgrades into one line item that finance can forecast. Medusa removes the licence fee and the transaction cut, and in exchange a self-hosted ecommerce platform moves those responsibilities onto your team or your partner: infrastructure, monitoring, upgrades, integrations, and the engineering time to own all of it.

For businesses with genuine complexity, such as B2B pricing rules, multi-warehouse inventory, marketplace payouts or unusual fulfilment logic, that trade is often clearly worth it, because the alternative is paying a platform to fight its own assumptions. For an online store whose requirements are almost entirely standard retail, the flexibility being purchased in complexity is flexibility that may never get used.

How to reduce the uncertainty: model three-year total cost of ownership rather than launch cost, covering hosting, annual maintenance as a percentage of build, and the custom integrations from point 5, then compare it against SaaS subscription plus transaction fees at your projected volume. The crossover point is real and it depends entirely on your scale and your complexity.

Where Medusa asks for more than it gives back

Every point above is manageable. But the platform makes specific demands, and where those demands go unmet, the flexibility stays unused while the complexity remains. Medusa asks for:

• Ongoing engineering ownership, in-house or contracted. Not a one-time build. The infrastructure, the upgrades and the integrations continue after launch.
• Requirements that come from a non-standard business model. The customisation power is the product. Where a business runs on conventional retail flows, that power is cost without return.
• Tolerance for a moving platform. Frequent releases, occasional rough edges, and documentation that trails the code.
• Comfort owning infrastructure, or a partner who owns it on your behalf.
• A budget that extends past launch. Maintenance, upgrades and incident response are recurring, not optional.

Where all five are in place, the disadvantages of Medusa.js are a project plan. Where several are missing, they compound, and the platform that was chosen for flexibility becomes a system nobody has the capacity to change.

Where to go next

If you are scoping a real Medusa project, the useful next questions are usually concrete: which integrations you actually need, what your infrastructure will cost to run, and who owns it in twelve months.

• Medusa.js development services: how we build, extend and maintain Medusa systems in production.
• Hire Medusa.js developers: for teams that need Medusa capability added to an existing engineering group. Page coming soon.
• Marketplace development: if what you are building has many sellers rather than one. Page coming soon.
• The other side of the ledger: the advantages, for balance.

We build on Medusa, including the parts described above. If you want a straight read on how the disadvantages of Medusa.js apply to your specific project, and what they would cost to manage, talk to our Medusa team and we are glad to go through it with you.

Frequently asked questions