Medusa vs Vendure vs Saleor: A Production Comparison

Every comparison of Medusa, Vendure, and Saleor I have found online is a feature list rewritten from the docs. Nobody states their production allegiance or pulls the repo numbers. And nobody mentions that one of the three is not MIT-licensed at all.

So let me state mine upfront: I run Medusa in production (a marketplace with 10,000 products and 50 vendors), and that is the platform I know at operator depth. Vendure and Saleor I know from evaluation and architecture work, not from carrying a pager for them. Read this comparison with that bias disclosed; everything factual below is source-checked as of August 27, 2026, so you can separate my judgment from the data.

TL;DR: All three are serious, actively developed headless commerce platforms. Medusa (TypeScript, MIT core) maximizes ownership and customization depth. Vendure (TypeScript/NestJS, GPLv3 + commercial license) is the most batteries-included TypeScript option. Saleor (Python/Django, BSD-3, GraphQL-only) is the choice for Python teams and GraphQL-pure architectures. Pick by team stack — the feature tables are nearly interchangeable.

The three platforms at a glance

All numbers checked 27 August 2026 via the GitHub API (medusajs/medusa, vendure-ecommerce/vendure, saleor/saleor) and each vendor's pricing page.

Architecture: three philosophies, not three feature sets

Medusa is a commerce framework more than a platform: commerce modules (products, orders, payments, inventory) plus a workflow engine with per-step rollback, exposed over REST APIs, with the storefront as a separate Next.js starter. You assemble a system rather than configure one. That is exactly why it customizes so deeply, and exactly why it needs a real team; I wrote up the cost consequences in my Medusa vs Shopify breakdown.

Vendure sits closer to a finished platform. Built on NestJS, the enterprise TypeScript framework, with a GraphQL API, it brings the structure NestJS teams already know: modules, dependency injection, decorators. Of the three, it feels most like "a commerce product you extend" while staying in TypeScript. If your organization already runs NestJS services, Vendure will feel like home on day one.

Saleor is the purist of the three. Python, Django, and the API is GraphQL only — the README's own words are "GraphQL native, API-only." Extension happens through apps and webhooks rather than in-process plugins, which keeps the core clean and pushes customization to the edges. It requires Python 3.12+ and Django 5.2, a modern and disciplined stack.

None of these philosophies is wrong. They select for different teams.

Licensing: the fine print nobody reads

This section alone justifies the article, because the three licenses are not interchangeable:

• Medusa: MIT for the core, with one precision most comparisons miss: the LICENSE file explicitly carves out "Enterprise Edition materials" governed by a separate commercial license. The framework you self-host is MIT; know which packages you pull in.
• Saleor: BSD-3-Clause. Permissive, no surprises. Verified via the GitHub license API, since "BSD-3" gets asserted in many places that turn out to be wrong about other platforms.
• Vendure: GPLv3 by default. Copyleft. For a plain shop backend this is usually workable, but if your commerce layer will embed proprietary business logic you do not want to open-source, you need the Vendure Commercial License from Vendure GmbH: a written agreement, not a checkbox. Plenty of teams discover this after the prototype. Check it before.

A concrete scenario for the Vendure case, because abstract license talk rarely lands: you build a marketplace whose commission engine encodes your negotiated vendor terms. Under GPLv3, distributing that software means providing source; whether your deployment counts as distribution is a question for your lawyer, not your tech lead — and the commercial license exists precisely so you never have to ask it. Medusa and Saleor sidestep the question entirely.

If your legal department has strong opinions, this table may end your evaluation faster than any benchmark.

Developer experience and time to production

Here I can only be fully first-hand about one platform, so I will label the rest as informed judgment. With Medusa, my own path from create-medusa-app to a production marketplace ran through weeks of real development; the framework gives you speed on the boring parts and full responsibility for the rest. The operational shape (separate worker process, Redis, PostgreSQL, S3-compatible storage) is documented and, once set up, has been quietly uneventful for me: two-to-three-minute parallel builds on Railway, zero infrastructure incidents since go-live.

Vendure's NestJS foundation means the learning curve tracks your NestJS familiarity almost one-to-one; for teams with that background, early velocity is likely the best of the three. Saleor's app-and-webhook extension model trades some in-process power for upgrade safety — customizations live outside the core, which ages well but means more moving parts on day one.

One honest generalization from evaluations: time-to-first-demo is similar across all three. Time-to-production diverges based on how far your requirements sit from each platform's happy path — which is a team-and-requirements question, not a platform ranking.

Ecosystems and extensions

The extension stories mirror the architectures. Medusa extends in-process: modules, workflows, and admin widgets in your own TypeScript, plus an official AI tooling layer (MCP server, agent skills) that has no equivalent at the other two; what it lacks is a large catalog of finished third-party plugins — you build more, install less. Vendure runs a curated plugin system in classic NestJS style, with core-team plugins for the usual suspects (search, payments, assets) and a smaller third-party ring around them. Saleor pushes extensions out of process entirely: apps talk to the core over GraphQL and webhooks, which keeps upgrades calm and makes the ecosystem feel more like integrations than plugins.

The practical consequence: none of the three has a Shopify-style app store that replaces development. Whichever you pick, the ecosystem shortens your work; it does not remove it.

Cloud offerings and lock-in: three very different bets

The managed offerings differ more than the frameworks do:

• Medusa Cloud: four tiers from $29 to $299 per month plus custom Enterprise, usage-based overages, and an explicit no-lock-in FAQ (export your data, move to self-hosting).
• Vendure Platform: a flat annual subscription "with no GMV, order, user, or separate capability fees", but every project is quoted individually; there is no public price. Budgeting means a sales conversation.
• Saleor Cloud: seats at a different table entirely. Select is $1,599/month up to $200,000 monthly GMV with 0.8% on overage; Volume is $3,999/month up to $1M GMV with 0.4%. That is enterprise pricing with a GMV meter, and it tells you who Saleor Cloud is for.

Saleor Cloud also sells onboarding as a product: an Accelerator Plan at $6,000 one-time and Forward Deployed Engineering at $12,000 one-time, both fully credited back over the first year. That is not a criticism — enterprise onboarding costs money everywhere — but budget lines like these tell you the expected customer size more honestly than any marketing page.

The self-hosting escape hatch exists for all three (that is the point of open source), but notice the models: Medusa prices like infrastructure, Vendure like a license, Saleor like an enterprise platform. Your finance team will have opinions.

Project health: the numbers, dated

Repo metrics do not measure quality, but they measure momentum and bus factor, and they are checkable. As of August 27, 2026:

Two readings worth adding. First: Vendure's v3.7.2 included a fix for a critical privilege-escalation vulnerability, which cuts both ways: a serious bug existed, and the team patched it promptly in a dated release. That is what responsible maintenance looks like; platforms without published security fixes usually just have unpublished bugs. Second: all three clear the abandonware bar by a wide margin. This comparison is between living projects, a luxury the wider open-source commerce category does not always offer.

Who should pick what

Pick Medusa if your team lives in TypeScript and the commerce system is a product, not a shop: deep custom logic, marketplace ambitions (the Mercur layer exists only here, and my marketplace build guide walks the path), ERP orchestration, and full code ownership. This is what I run, and everything on this blog's e-commerce topic page documents that path, including how AI agents accelerate Medusa work.

Pick Vendure if you are a NestJS shop wanting the most platform-like TypeScript option, and the GPLv3-or-commercial-license question has a clean answer for your business. For structured enterprise TypeScript teams it is arguably the most comfortable of the three.

Pick Saleor if your engineering organization is Python-first or your architecture mandates GraphQL end to end. It is the most opinionated and the most disciplined. Both are strengths, if the opinions match yours.

And if you evaluate hands-on — which beats this article — structure a week per platform: model one non-trivial piece of your own domain logic (not the demo shop), wire one real payment flow, run one deploy to your actual infrastructure, and note where the docs left you alone. The platform that survives your weirdest requirement wins; all three survive the normal ones.

A note on switching later: these three do not migrate into each other cheaply. The data models differ, and a storefront written against GraphQL does not talk to REST without a rewrite of the client layer. Treat the choice as a multi-year commitment, which is one more reason to weight team fit over feature checklists.

Pick none of them if your shop is standard and your developer capacity is thin; that argument is the same one I made against my own stack in the Shopify comparison, and it applies to all three headless platforms equally.

If you want this decision made against your actual requirements rather than a general framework, that is literally what my fullstack development engagements start with. And if you only need the evaluation, two weeks of PoC Sprint on your data answers it more reliably than any article, including this one.