Medusa vs WooCommerce: free to start, paid to maintain

Choose WooCommerce if your store fits the standard: a straightforward catalogue, one market, content and commerce in a single system, and maintenance that has to stay cheap and hireable almost anywhere. Choose Medusa if your selling logic, your product model or your integrations have outgrown what a stack of extensions can express, and you have someone to maintain your own code instead of somebody else’s.

Both are free to install and both leave the code and the database on your side. That symmetry removes most of the arguments you see in comparisons against hosted platforms: no revenue share, no plan tiers, no vendor who can rewrite the terms. What is left is a duller question. What does it cost to keep alive a thing you already own?

Since the licence costs nothing on both sides, setting a platform price against a build price compares two different things. The bill splits into three layers and that is how we break it down here: licence, build, running cost. Then a fourth line nobody budgets for, the price of the first change after launch.

Free to start is where the similarity ends

The common mistake is to file WooCommerce under “free” and Medusa under “expensive”. Both are open source. WooCommerce is a free plugin for WordPress, stewarded by Automattic, and the Medusa core ships under the MIT licence, with separate terms for its Enterprise edition.

Three things look identical on both sides. Set them aside before comparing anything else.

• No revenue share. WooCommerce states 0% revenue share; Medusa states a 0.0% GMV platform fee, including on its Cloud plans. You pay your payment processor, not the platform.
• The data is yours. MySQL or MariaDB behind WooCommerce, PostgreSQL behind Medusa, both on infrastructure you control.
• Hosting is your job. Neither one runs a server for you unless you buy a managed service on top.

Split the bill before you compare it

The fairest way to price this decision is to break it into layers and say where each number came from. The first layer is identical on both sides. The second and the third are where these platforms genuinely part company.

Net of tax. The WooCommerce build and running figures come from agencies in the Polish market and were collected on 12 August 2026; they differ between suppliers, so treat this as a band rather than an average. Our own ranges are set in Polish złoty (from 60,000 PLN, typically 80,000 to 200,000 PLN for the build, from 3,500 PLN a month for care) and converted here at a rounded 4.30 PLN to 1 EUR, the NBP mid rate of 11 August 2026. Vendor-published hosting and extension prices are in the table below, checked 11 August 2026.

Two caveats about where those numbers come from. Neither vendor publishes a build price, so the left column is a market rather than a price list. One data point circulates on the Medusa side, a Gdańsk agency quoting “from around $20,000”, but a single point is not a range and its scope is unknown.

The band is also local. Rates decide a build price more than the engine does: agencies in Eastern Europe quote 40 to 70 USD an hour against 70 to 100 in Western Europe, with Poland clustering at 50 to 99 on Clutch. Read the figures above as our market, then reprice them for yours.

“Further up” has a specific address. It begins where WooCommerce stops being cheap as well, in its own 5,800 to 14,000 EUR band and above, because by then the price is set by integrations, data migration and selling logic. At that level you are comparing two projects, not two licences.

That is a range, not a quote. The exact number falls out of a conversation about your catalogue, your integrations and the state of your data. The pricing model itself is set out on our pricing page.

Twelve dimensions, side by side

This table holds only what can be checked at source: vendor pages, documentation, the repository. None of the figures below is an estimate of ours or a quote from anybody else.

Checked 11 August 2026. Sources: woocommerce.com (server requirements, pricing), wordpress.org, docs.medusajs.com, medusajs.com/pricing, github.com/medusajs/medusa. Amounts are quoted in the currencies the vendors publish. We revisit this table quarterly.

Where the WooCommerce bill actually arrives

Not in a licence, because there is none. It arrives in four places, none of them alarming on its own, which together become a line item nobody put in the budget.

An extension is not a feature, it is somebody else’s code in your checkout

Anything WooCommerce does not do natively gets closed with an extension: subscriptions, contract pricing, tax rules, shipping logic, channel feeds. WooCommerce prices extensions at $29 to $299 a year each, and its own Subscriptions extension at $279 a year.

The money is the smaller half of this. The larger half is that after a year your buying path is assembled from the work of a dozen independent authors, each with a separate release cadence, a separate quality bar and separate plans for the future.

Four clocks that do not tick together

An update in this stack is not one event. Four independent clocks are running, and it is the drift between them, rather than any single release, that puts the checkout at risk:

• PHP. WooCommerce now asks for 8.3 or greater and tests up to 8.4, describing older branches as past their official end of life.
• WordPress. Version 6.9 or greater is required, and core moves more often than most extensions do.
• WooCommerce itself. Version 11.0.1 on the day we checked, across seven million or more active installations.
• Every extension, separately. A different author, a different pace, a different decision about whether to keep up at all.

Nobody tests your particular combination before shipping, because your combination exists only on your site. In practice that means a staging environment and a person who looks at it before anything reaches production. That is the hour a month that never shows up on an invoice.

Security here is an ecosystem statistic, not a scare story

Patchstack, a company that sells WordPress security, reports in “State of WordPress Security in 2026” that 11,334 new vulnerabilities were found across the WordPress ecosystem during 2025, a 42% increase on the year before. 91% of them were in plugins and 9% in themes, while core accounted for six, described as low priority.

Two honest caveats. The source is a security vendor, so it has an interest in the number landing hard. And the figure covers the whole WordPress ecosystem rather than WooCommerce, so it says nothing about your store. What it does say is where the attack surface sits: in the extension layer, which is the layer you choose.

Large catalogues: what HPOS fixed, and what it did not

The most repeated criticism, that WooCommerce keeps orders in the WordPress posts tables, is out of date. Since version 8.2 High-Performance Order Storage gives orders dedicated tables and indexes, enabled by default on new installations. WooCommerce presents it directly as an answer to scalability, reliability and a simpler data structure.

We have not benchmarked either platform and will not put numbers here. What can be said is where the architecture creates exposure: on WooCommerce, performance depends on the sum of every extension installed, because each one adds its own queries and scripts. HPOS tidies the core, not what the extensions do. What breaks first as traffic climbs we cover separately in what breaks at 10x traffic.

One installation for content and for commerce

The store and the blog share an installation, a database and an admin. That is an advantage until it turns into a cost: a change in the content layer can reach the sales path, and article traffic shares resources with the cart.

Medusa draws that boundary by design, because commerce lives behind an API while the storefront and the content layer can stand apart. That is not better in itself. It is better when you genuinely need separate release paths for content and for selling, which is what we mean by headless architecture.

What Medusa gives you, and what it charges in return

Medusa is a commerce backend in TypeScript, arranged in four layers: API routes, workflows holding the business logic, domain modules, and a PostgreSQL data store. Payment, fulfilment, CMS and search providers are swapped as modules rather than forked into the core.

• A product model shaped around your assortment. Made-to-measure goods, bundles, configurations and parameter-driven pricing do not have to end up in description fields.
• Selling logic as code, not as a workaround. Contract pricing, order approvals and your own discount rules are written as workflows instead of assembled from three extensions.
• One boundary for many channels. The same backend serves the web store, an app and your integrations, because everything travels through the API.

The bill for that is simple and worth stating plainly. The third-party extension problem disappears and a staffing requirement takes its place: TypeScript, PostgreSQL, DevOps, and integrations nobody has written for you. One cost is exchanged for another, not removed.

The price of the first change after launch

This is the line that decides the most and appears in no build budget. The question is plain: what does the first thing you ask for three months after going live actually cost?

On WooCommerce a change outside the standard is usually another extension. Along with the feature you buy its annual licence, its author, that author’s release schedule and the risk of a clash with the rest of the stack. It is the same layer the vulnerability figures above describe: the surface grows with every entry on the list.

On our side the same change is a backlog item, on code that belongs to you. You pay for the work rather than for a new dependency, and once it ships there is nothing extra to keep updated with every future release.

What an extension will not do

So far we have compared the cost of the same thing. There is one layer where the two platforms do not stand level, because everything in it depends on access to your data and to your selling logic: the work AI can take over.

On our side that is a separate stage with a price. AI Automation is scoped per workflow, from about 1,400 EUR each (6,000 PLN at the same rate as above), and the scope is usually dull and countable:

• Product descriptions generated from attributes rather than from nothing.
• Catalogue translation when you open another market, covered separately in AI catalog translation.
• Marketplace feeds: mapping catalogue columns onto channel fields and validating the file before it goes out.
• Order status handling and the answers to questions about a shipment.
• Attribute mapping between an ERP export and your product model.

The second part is running a store through AI agents. The condition is not the model, it is the backend: your own code, your own database and an API the agent can reach in full. Where a store is assembled from third-party extensions, that reach ends at the edge of each extension’s API.

None of this is out of reach on WooCommerce. It usually arrives as another extension or an integration with an external SaaS: its own subscription, its own lifecycle, its own access to your data. That is not an accusation, it is a different bill. You buy a finished feature instead of building a capability.

Choose WooCommerce when

This section is not a courtesy to a competitor. WooCommerce wins in situations that describe the majority of stores trading today.

• The catalogue fits the standard. A few hundred products with simple variants, one market, one currency, straightforward retail.
• Content is part of how you sell. Articles, guides and the store in one admin is a real saving in labour, not an architectural flaw.
• The starting budget is close to zero. The core costs nothing and early gaps close with an off-the-shelf extension rather than a build.
• You have no technical team. WordPress talent is available in almost every market, and replacing a supplier does not mean rewriting the store.
• You are still testing whether the product sells. At that stage every unit of budget spent on architecture is one not spent on validating the hypothesis.

One more thing, even though we build on Medusa. If your list of grievances with WooCommerce comes down to slow hosting and twenty extensions accumulated over the years without review, that is not an argument for changing platform. It is an argument for a cleanup.

When this choice is even on the table

Most stores have no decision to make here, because they fit the standard, and for them WooCommerce is the cheaper answer. The engine question turns real only when specific things are visible inside the business. Five markers tell us it has:

• The catalogue does not fit a standard product model. Made-to-measure goods, bundles, configurators, prices derived from parameters. The symptom is easy to spot: data that should live in fields lives in the description or in a spreadsheet next to it.
• Selling logic is the advantage, not the paperwork. B2B contract pricing, credit limits, order approvals, rules per customer. If that is why people buy from you, it should not live inside somebody else’s extension.
• ERP and warehouse integrations set the pace. Not the storefront, but stock, prices, documents and statuses. In that kind of project the front end is the smallest problem you have.
• You sell across several channels at once. Store, marketplace, app, wholesale. Each channel wants the data its own way, and the source of truth has to stay singular.
• The sum of the extensions has become an operational risk. Not their number, but the fact that an update has become an event somebody holds their breath through.

Recognise none of these? Then the choice does not concern you, and moving to Medusa buys control you will not use. Recognise several? One condition still outweighs the whole table: you need somebody to maintain it, an in-house team or a partner on retainer. Without that, Medusa is the wrong call regardless of its merits.

The question that decides more than the technology

Who runs this in two years? It sounds like a procurement footnote and it usually outweighs everything in the table above, because both platforms hand you the code and, with it, the responsibility.

The hiring pool is not symmetrical. WordPress and PHP is a wide market in every region; Node.js with Medusa is a much narrower one. Integration coverage tilts the same way: Medusa documents Stripe and PayPal for payments and ShipStation for fulfilment, so a regional gateway or carrier is a module you commission rather than a subscription you renew.

What this comparison does not cover

The boundaries, stated plainly, so the piece can be used as a source:

• Performance under load. We measured neither platform and we do not repeat other people’s benchmarks.
• A quote for your project. The layer table holds a market band on the WooCommerce side and our own published ranges on the Medusa side, not an offer. The number follows scope, integrations and the state of your data; the pricing model is on the pricing page.
• What other Medusa suppliers charge. We publish ours because nobody in this market publishes theirs. If you are collecting proposals, compare the scopes before you compare the totals.
• Build costs outside the Polish market. Our figures describe the market we work in. Hourly rates move them substantially between regions, so treat them as a reference point rather than a global benchmark.
• Individually negotiated terms. Managed hosting and enterprise support are frequently priced per customer.
• Comparisons with hosted platforms. Shopify and PrestaShop are a different conversation; the routes out of them sit on Shopify migration and PrestaShop migration.
• Anything after today. Vendor versions, requirements and prices were checked on 11 August 2026, and the build and running bands on 12 August 2026. We return to both quarterly.

How to decide without guessing

The sequence that saves the most money is a dull one, and it produces three lists:

• List one: what is impossible today. Everything your current platform cannot do that is on the plan for the next eighteen months.
• List two: the price of standing still. A year of running what you already have: hosting, extensions, and the hours spent on updates and workarounds.
• List three: how many changes last year. Count the times you needed something outside the standard, and how many of those an extension actually closed. It is the best available proxy for what change will cost you next.

Only with both lists does an engine comparison mean anything, because you can see what you are buying. The framing sits in our pieces on criteria for choosing a platform and the signs a store has outgrown its platform, and the arithmetic in the three-year TCO.

Medusa is only the foundation here. What we build on it is BEAM: one place a client runs their whole eCommerce from, delivered in four stages, from Blueprint through Engineering to Maintenance & Growth. If the numbers land on Medusa, the scope is set out on Medusa development; if they land on WooCommerce, we will say so rather than sell a build that will not pay for itself. A wider view of the platform families is on eCommerce platforms.

Both platforms cost nothing to license, and both send the invoice somewhere else. On WooCommerce you pay in maintenance and in the next extension for the fact that entry was free. On Medusa you pay in the build and in the people, and you get selling logic you control and a predictable price for changing it. The decision comes down to which of those invoices you would rather receive.