Medusa vs Magento (Adobe Commerce): darmowa licencja, płatna decyzja

Wybierz Magento Open Source albo Adobe Commerce, jeśli potrzebujesz dojrzałego panelu sprzedażowego z pudełka, szerokiego katalogu rozszerzeń i wykonawcy, którego znajdziesz w każdym większym polskim mieście. Wybierz Medusę, jeśli logika sprzedaży ma być Twoim kodem w TypeScripcie, a nie konfiguracją cudzego monolitu w PHP, i masz kim ten kod utrzymywać.

To porównanie prawie zawsze zaczyna się od złego pytania. Pada „ile kosztuje licencja”, odpowiedź dla Magento Open Source brzmi zero złotych i rozmowa się kończy, zanim zdążyła się zacząć. Licencja jest najmniejszą pozycją w tym rachunku po obu stronach.

Dlatego rozbijamy to na trzy rachunki: licencję, wdrożenie i to, co dzieje się po starcie.

Licencja jest darmowa, wdrożenie już nie

Magento Open Source wychodzi na licencji Open Software License 3.0. Repozytorium magento/magento2 formułuje to wprost: każdy plik źródłowy w dystrybucji jest objęty OSL 3.0 albo warunkami właściwego dokumentu zamówienia. Rdzeń Medusy stoi na licencji MIT, z osobnymi warunkami dla wydania Enterprise. Po obu stronach zero opłat za sam silnik i zero prowizji od obrotu.

Następna pozycja rachunku wygląda już inaczej. Polskie agencje Magento publikują swoje widełki i są to liczby, których nie spodziewa się nikt, kto przyszedł tu po argument „Magento jest darmowe”. Smartbees podaje 80 000-150 000 zł netto za wdrożenie B2C na gotowym szablonie w wersji Open Source, 150 000-300 000 zł i więcej za dedykowaną platformę B2B oraz 400 000 zł i więcej przy zakresie enterprise. Advox operuje na jeszcze wyższych progach budżetowych: 200 000 zł, 500 000 zł i milion złotych, przy stawkach deweloperskich 200-250 zł netto za godzinę.

Dwie uczciwe uwagi do tych liczb. Pochodzą od dwóch różnych wykonawców i opisują różne zakresy, więc nie są porównaniem jeden do jednego. Żaden z nich nie jest też dostawcą platformy. To agencje, które na Magento budują, a ich cennik opisuje rynek, nie produkt.

Kwoty netto. Widełki po stronie Magento pochodzą od dwóch polskich agencji Magento i opisują rynek, nie cennik dostawcy: Smartbees (aktualizacja 14 maja 2026) oraz Advox Studio (20 stycznia 2026). Widełki po stronie Medusy są nasze i publikujemy je w całości. Dane Adobe i Medusy sprawdzone u źródła 12 września 2026. Do tabeli wracamy raz na kwartał.

Nasze własne widełki publikujemy dlatego, że nikt na rynku Medusy tego nie robi. Po stronie Magento jest odwrotnie: agencje publikują, więc da się zebrać pasmo rynkowe. Model wyceny opisujemy na stronie cennika, a pełny rachunek na trzy lata w tekście o koszcie sklepu na własność.

Adobe Commerce ma cenę, której nie sprawdzisz

Adobe nie publikuje cennika Adobe Commerce i mówi to własną dokumentacją. W opisie limitów Adobe Commerce Optimizer stoi zdanie, że bazowy przydział zasobów jest wyznaczany na podstawie progu GMV, czyli wartości sprzedaży przepuszczonej przez platformę. Wysokości progów w tym dokumencie nie ma. Po nią Adobe odsyła do przedstawiciela handlowego albo do wsparcia.

W sieci krążą kwoty rzędu kilkudziesięciu tysięcy dolarów rocznie. Pochodzą od integratorów i serwisów porównujących platformy, więc traktuj je jak plotkę rynkową o właściwym rzędzie wielkości, nie jak ofertę. Jedna z polskich agencji Magento podaje w swoim artykule 30 000-50 000 USD rocznie i dopisuje, że cena rośnie z przychodem. Adobe tego nie potwierdza ani nie zaprzecza, bo po prostu nie mówi.

Praktyczny skutek jest jeden: budżetu Adobe Commerce nie policzysz bez handlowca Adobe.

B2B leży po stronie płatnej licencji

Tu jest najważniejsza rzecz w całym tym porównaniu i większość zestawień ją pomija. Funkcje B2B, po które hurtownie w ogóle patrzą na Magento, nie są częścią Magento Open Source. Adobe opisuje je jako rozszerzenie Adobe Commerce B2B i w swojej dokumentacji dopisuje wprost, że jest ono dostępne tylko dla Adobe Commerce i wymaga osobnej licencji.

Za tą granicą licencyjną siedzi dokładnie ten zestaw, o który pyta każdy projekt hurtowy:

• Konta firmowe: struktura organizacji, wielu kupujących, role i uprawnienia zakupowe pod jednym kontem.
• Katalogi współdzielone: zamknięta oferta i własne ceny dla konkretnego klienta.
• Negocjowane oferty: ścieżka zapytanie, oferta, akceptacja zamiast zwykłego koszyka.
• Listy zamówieniowe i szybkie zamówienie: powtarzalne zakupy bez przeklikiwania katalogu.
• Zamówienia zakupowe: obieg akceptacji i kontrola wydatków po stronie kupującego.

Po stronie Magento Open Source zostają dwie drogi: kupić rozszerzenie B2B u firmy trzeciej albo napisać tę logikę samemu w PHP. Obie kończą się tym, co miało być argumentem przeciw Medusie, czyli własnym kodem do utrzymania. Medusa daje w rdzeniu grupy klientów i cenniki, ma oficjalny starter B2B, a resztę reguł handlowych zapisuje się jako workflow. Różnica sprowadza się do tego, w jakim języku i na czyim fundamencie ten kod powstaje.

Jak wygląda taki zakres w praktyce, rozkładamy przy platformach B2B i w tekście o integracji sklepu B2B z ERP. To zwykle ERP, nie front, wyznacza tempo takiego projektu.

Sześć usług do utrzymania albo dwie

Magento jest monolitem PHP z długą listą zależności infrastrukturalnych, a Medusa aplikacją Node.js z jedną bazą. Brzmi jak szczegół techniczny, dopóki ktoś nie zacznie płacić za utrzymanie obu tych rzeczy przy życiu.

Wymagania Magento 2.4.9 według strony wymagań systemowych Adobe (aktualizacja 11 sierpnia 2026), wymagania Medusy według dokumentacji instalacji Medusy. Obie kolumny sprawdzone 12 września 2026. MySQL 8.0 straciło wsparcie 30 kwietnia 2026, a Elasticsearch 7.17 15 stycznia 2026, więc starsze instalacje mają już policzony czas.

Ta lista ma dwa skutki, oba widoczne w budżecie. Pierwszy to hosting: stos, który wymaga OpenSearcha, RabbitMQ i Valkeya, kosztuje więcej niż aplikacja z jedną bazą. Dlatego polskie agencje podają hosting Magento od około 1 500 zł miesięcznie. Drugi to bieżnia wersji. Adobe co roku podnosi wymagane wersje komponentów, więc utrzymanie Magento oznacza cykliczne podnoszenie całego stosu, nie tylko samej aplikacji.

Bezpieczeństwo: wrzesień 2026 jako materiał dowodowy

Kilka dni przed publikacją tego tekstu ekosystem Magento przeszedł przez zdarzenie, które opisuje realny koszt utrzymania lepiej niż każda tabela. CVE-2026-75650, nazwana przez badaczy StyleSmuggler, to zdalne wykonanie kodu bez uwierzytelnienia z oceną CVSS 10.0, obejmujące Magento Open Source, Adobe Commerce i Adobe Commerce B2B w wersjach od 2.4.4 do 2.4.9. Sansec datuje początek aktywnej eksploatacji na 4 września 2026, a hotfiks Adobe na 7 września.

Trzy dni okna mówią o architekturze obowiązków więcej niż każda deklaracja dostawcy. Adobe wydaje jeden pełny pakiet poprawek rocznie, w maju, a poza tym publikuje wyodrębnione łatki bezpieczeństwa wtedy, gdy są potrzebne. Wszystko poniżej tej linii, czyli wdrożenie łatki na Twojej instalacji w ciągu godzin zamiast tygodni, jest po Twojej stronie.

I teraz uczciwa druga strona, bez której ta sekcja byłaby nagonką. Medusa nie ma ani jednego opublikowanego zgłoszenia bezpieczeństwa w repozytorium na GitHubie, co brzmi świetnie i znaczy niewiele. Magento jest na rynku od kilkunastu lat, ma wokół siebie osobny przemysł badaczy bezpieczeństwa i jest celem wartym ataku. Medusa jest młodsza, mniejsza i nikt jej nie skanuje w takiej skali. Brak zgłoszeń mierzy więc uwagę badaczy, a jakość kodu dopiero w drugiej kolejności.

Model sprzedaży jako kod

Medusa jest backendem sprzedaży w TypeScripcie: trasy API, workflow z logiką biznesową, moduły domenowe i PostgreSQL pod spodem. Dostawcę płatności, wysyłki, CMS-a czy wyszukiwarki wymienia się jako moduł, bez forkowania rdzenia. Trzy rzeczy, które z tego wynikają dla sklepu:

• Model danych pod Twój asortyment. Produkty na wymiar, zestawy i ceny liczone z parametrów nie muszą lądować w polach opisowych ani w arkuszu obok.
• Reguły handlowe jako kod. Cenniki kontraktowe, limity kupieckie i akceptacje zamówień piszesz w workflow, zamiast składać z trzech rozszerzeń różnych autorów.
• Jedna granica dla wielu kanałów. Sklep, aplikacja, hurt i integracje idą przez to samo API, więc źródło prawdy zostaje jedno.

Rachunek za to trzeba powiedzieć wprost, bo inaczej cały tekst byłby ulotką. Kupując Medusę, kupujesz potrzebę zespołu: TypeScript, PostgreSQL, DevOps i integracje, których nikt za Ciebie nie napisał. Polskiej bramki płatniczej ani paczkomatów nie znajdziesz w oficjalnej dokumentacji Medusy, więc wchodzą do zakresu wdrożenia jako praca. Na Magento są dostępne jako rozszerzenie i to jest realna przewaga, którą trzeba policzyć przed decyzją.

Kiedy wybrać Magento albo Adobe Commerce

Ta sekcja nie jest kurtuazją. Budujemy na Medusie i mimo to w kilku sytuacjach powiemy, że Magento jest lepszą odpowiedzią, bo tak wychodzi z rachunku, a nie z sympatii.

• Masz już Magento i ono działa. Jeśli lista zarzutów sprowadza się do wolnego hostingu i dwudziestu rozszerzeń zbieranych latami bez przeglądu, to argument za porządkami, nie za zmianą platformy.
• Potrzebujesz dojrzałego panelu z pudełka. Merchandising, wielosklepowość, podatki, CMS i staging treści Magento ma od lat. Medusa daje panel, nie gotowy kombajn handlowy.
• Liczy się dostępność wykonawców. Rynek Magento w Polsce jest szeroki i przejrzysty do tego stopnia, że agencje publikują widełki na swoich stronach. Po stronie Medusy takiej przejrzystości nie ma.
• Jesteś już w stosie Adobe. Jeśli pracujesz na AEM, Analytics czy Experience Platform, integracja Adobe Commerce z tym zestawem jest przewagą, której nie odtworzymy projektem integracyjnym w rozsądnym budżecie.
• Chcesz zostać przy open source bez Adobe. Mage-OS, wspólnotowa dystrybucja zbudowana na Magento 2.4.9, wydaje własne wersje i daje ścieżkę niezależną od komercyjnych priorytetów Adobe.

Dorzucimy jeszcze jedno, choć działa przeciw nam. Jeśli potrzebujesz standardowego sklepu B2C na szybko, Magento też nie jest najtańszą drogą, a widełki z tego tekstu pokazują dlaczego. W takim wypadku sensowniejsze bywa WooCommerce albo Shopify. Mówimy to wprost.

Migracja z Magento: kolejność, która nie kosztuje sprzedaży

Najczęstszy powód, dla którego ktoś czyta ten tekst, to Magento, które przestało nadążać: wersja po końcu wsparcia, katalog rozszerzeń, którego nikt nie chce ruszać, i zakres prac rosnący przy każdej aktualizacji. Sygnały, po których poznajemy, że sklep faktycznie wyrósł z obecnej platformy, zebraliśmy w tekście o zmianie platformy, a sam przebieg przenosin bez przerwy w sprzedaży opisuje migracja bez zatrzymywania sprzedaży.

Najpierw data końca wsparcia Twojej wersji

Zanim ruszysz projekt migracyjny, sprawdź jedną datę. Adobe podaje koniec regularnego wsparcia na 31 maja 2027 dla 2.4.7, 31 maja 2028 dla 2.4.8 i 31 maja 2029 dla 2.4.9. Jeśli masz jeszcze 2.4.6, regularne wsparcie skończyło się 11 sierpnia 2026, a rozszerzone kończy się 31 sierpnia 2027. Ta data wyznacza okno na decyzję lepiej niż każdy argument architektoniczny.

Potem front, bo tam Adobe zmienia zasady

Nowe narzędzia storefrontowe Adobe, czyli drop-iny na Edge Delivery Services, wymagają licencji Adobe Commerce as a Cloud Service albo Adobe Commerce Optimizer, a dokumentacja dopisuje, że dla pozostałych typów wdrożenia nie są dostępne. Dla sklepu na Magento Open Source oznacza to, że nowoczesna ścieżka frontendowa Adobe jest zamknięta licencją. Otwarta zostaje inna: Hyvä, szeroko używany motyw frontendowy dla Magento, jest według swojej strony licencyjnej w pełni otwarty i darmowy.

Granice tego porównania

Stawiamy je wprost, żeby dało się z tego tekstu korzystać jak ze źródła:

• Wydajność pod obciążeniem. Nie mierzyliśmy żadnej z tych platform i nie powtarzamy cudzych benchmarków.
• Cena Adobe Commerce. Brak danych publicznych. Nie podajemy szacunku, bo Adobe nie publikuje ani progów GMV, ani stawek.
• Wycena Twojego projektu. Widełki po stronie Magento to pasmo dwóch polskich agencji, po stronie Medusy nasze publikowane widełki. Żadne z tego nie jest ofertą.
• Widełki innych wykonawców Medusy. Podajemy własne, bo nikt na tym rynku swoich nie publikuje. Zbierasz oferty? Porównuj zakresy, nie same kwoty.
• Rynki poza Polską. Stawki godzinowe przesuwają koszt wdrożenia mocniej niż wybór silnika, więc liczby wyżej opisują rynek, w którym pracujemy.
• Stan po dacie publikacji. Wymagania, daty wsparcia i informacje o luce sprawdziliśmy 12 września 2026. Wracamy do nich raz na kwartał.

Jak podjąć tę decyzję bez zgadywania

Kolejność, która oszczędza najwięcej pieniędzy, jest nudna i mieści się w czterech pytaniach:

• Czego dziś nie da się zrobić? Wypisz to, czego obecna platforma nie umie, a co masz w planie na najbliższe osiemnaście miesięcy.
• Ile kosztuje status quo? Roczne utrzymanie tego, co już masz: hosting, rozszerzenia, godziny na aktualizacje i obejścia.
• Czy potrzebujesz funkcji B2B? Jeśli tak, policz je po obu stronach jako pracę albo jako licencję, bo w Magento Open Source nie ma ich w rdzeniu.
• Kto to utrzyma za dwa lata? Ta odpowiedź waży więcej niż cała tabela wyżej, po obu stronach.

Gdzie w tym jesteśmy my

Medusa jest u nas fundamentem, a nie tożsamością. To, co na niej budujemy, nazywamy BEAM: jedna platforma, z której klient prowadzi cały swój eCommerce, dowożona etapami, od Blueprintu przez Engineering po Maintenance & Growth. Wdrożenia zaczynają się od 60 000 zł netto i typowo mieszczą się w 80 000-200 000 zł, automatyzacje AI wyceniamy od 6 000 zł za workflow, a stała opieka startuje od 3 500 zł miesięcznie. Zakres pracy opisujemy przy wdrożeniach Medusy.

Uczciwe zastrzeżenie: jeśli rachunek wychodzi po stronie Magento albo Adobe Commerce, powiemy to zamiast sprzedawać wdrożenie, które się nie zwróci. A jeśli wąskim gardłem są kanały sprzedaży, a nie sama platforma, obsługę Amazona i Allegro prowadzi u nas marka siostrzana Amazonway.

Obie platformy zostawiają kod i dane po Twojej stronie, a rachunek wystawiają gdzie indziej. Na Magento płacisz utrzymaniem sześciu usług z tabeli wyżej, rocznym rytmem aktualizacji i licencją za funkcje B2B, jeśli ich potrzebujesz. Na Medusie płacisz wdrożeniem i zespołem, a w zamian dostajesz logikę sprzedaży w kodzie, który należy do Ciebie. Decyzja sprowadza się do tego, którą z tych faktur wolisz dostawać przez następne trzy lata.