Medusa или Saleor: что выгоднее и когда

MAATRIX

Если вы строите интернет-магазин на headless-платформе и выбираете между Medusa и Saleor, готового ответа «бери вот это» не существует — обе решают одну задачу разными средствами, и цена ошибки здесь не в деньгах на лицензию (обе бесплатны и open source), а во времени вашей команды на поддержку стека. Ниже — разбор без маркетинга: что каждая платформа тянет из коробки, сколько ресурсов сервера реально просит и в каких сценариях одна выигрывает у другой с большим отрывом.

Что это вообще такое

Medusa — headless-коммерс на Node.js/TypeScript. Ядро — модульный монолит (с версии 2.x официально позиционируется как «modular monolith»): заказы, корзины, товары, регионы, налоги живут в одном приложении, но собраны из отдельных модулей, которые можно заменять. Хранилище — PostgreSQL, кеш и очереди — Redis. Фронтенд не идёт в комплекте: обычно берут Next.js Storefront из стартер-кита или пишут свой поверх REST/JS SDK.

Saleor — тоже headless, но на Python/Django + GraphQL API. Ядро жёстче стандартизировано: единая GraphQL-схема, встроенная поддержка мультивалютности, скидок, подписок и B2B-логики на уровне ядра, а не аддонов. Хранилище тоже PostgreSQL, обязательно нужен Redis для Celery-очередей (обработка вебхуков, экспорт, email), плюс отдельный процесс Celery worker.

Уже на этом шаге видна первая развилка: Medusa — это один Node-процесс (плюс воркер для фоновых задач в проде), Saleor — это минимум три процесса (Django API, Celery worker, Celery beat) плюс возможный отдельный GraphQL federation gateway, если вы растёте.

Стек и что просить у сервера

По памяти на голом VPS для небольшого магазина (до нескольких тысяч SKU, невысокий трафик):

• Medusa: 2 vCPU / 4 ГБ RAM хватает с запасом — сам сервер съедает 300–500 МБ в простое, PostgreSQL и Redis укладываются в оставшееся. Это ориентир по опыту небольших проектов, не бенчмарк — при большом каталоге с полнотекстовым поиском аппетит растёт.
• Saleor: реалистичный минимум — 4 ГБ RAM, комфортно — 8 ГБ. Django + Celery worker + Celery beat вместе держат заметно больше базового оверхеда, чем один Node-процесс, а GraphQL-резолверы на сложных запросах (вложенные связи товар→варианты→атрибуты→склад) любят упереться в CPU при недостатке индексов.

Если сомневаетесь, сколько ресурсов закладывать на магазин в принципе (не только про эти две платформы), у нас есть отдельный разбор: сколько ресурсов нужно VPS для интернет-магазина.

Установка и первый запуск

Medusa стартует быстро — это одна из её сильных сторон:

# нужен Node.js 20+, PostgreSQL и Redis уже подняты
npx create-medusa-app@latest my-store
cd my-store
# .env: DATABASE_URL, REDIS_URL, JWT_SECRET, COOKIE_SECRET
npx medusa db:migrate
npx medusa develop

Продакшен-сборка — medusa build (собирает admin + backend) и запуск через medusa start за процесс-менеджером (pm2 или systemd) и Nginx/Caddy как обратный прокси.

Saleor разворачивается через Docker Compose — это официально рекомендуемый путь, руками из исходников поднимать сложнее из-за количества сервисов:

git clone https://github.com/saleor/saleor.git
cd saleor
# docker-compose.yml уже описывает api, worker, beat, db, redis
docker compose build
docker compose run --rm api python manage.py migrate
docker compose run --rm api python manage.py createsuperuser
docker compose up -d

Отдельно нужно поднять Saleor Dashboard (админку) — это отдельный репозиторий/образ, который обращается к GraphQL API. В сумме — больше движущихся частей на старте, но и Compose-файл уже описывает топологию за вас.

Если Docker на сервере ещё не настроен, у нас есть пошаговая установка: Docker Compose для продакшена на Ubuntu 24.04.

База данных и очереди: на что обратить внимание

PostgreSQL нужен обеим платформам, и обеим — не «просто установленный», а настроенный под нагрузку с транзакциями заказов: правильный shared_buffers, work_mem под сложные выборки, вовремя срабатывающий autovacuum. У нас есть руководство по установке и тюнингу: как установить и настроить PostgreSQL на VPS.

Разница в том, как каждая платформа использует Redis:

• В Medusa Redis — это кеш событий и очередь workflow engine (в 2.x заказы и другие процессы идут через шаги workflow, которые можно откатывать). Без Redis Medusa в dev-режиме падает на in-memory реализации — работает, но не переживёт рестарт процесса и не годится для нескольких инстансов.
• В Saleor Redis — обязательный брокер для Celery. Без него не работают вебхуки на внешние платёжные шлюзы, отправка email, экспорт каталога, синхронизация со складом. Это критичный компонент, а не опция.

Установка Redis — отдельная тема: как установить и настроить Redis на VPS.

Кастомизация: где реально считать трудозатраты

Здесь разница философий бьёт по срокам разработки сильнее всего.

Medusa — модульная архитектура, где кастомная логика пишется как отдельный модуль на TypeScript и подключается в medusa-config.ts. Плюс: низкий порог входа для JS/TS-команды, богатая типизация, можно расширить почти любую сущность (добавить поля, переопределить workflow-шаг). Минус: экосистема готовых плагинов заметно младше — многие интеграции (конкретные платёжные провайдеры, локальные ФНС/чеки для России, специфичные ERP) придётся писать самим или доверять сообществу, которое ещё формируется.

Saleor — единая GraphQL-схема, которую расширяют через собственные Apps (внешние сервисы, слушающие вебхуки платформы) или через синхронные/асинхронные webhook-подписки. Плюс: зрелая модель прав доступа, встроенная поддержка множественных каналов продаж (channels — разные цены/валюты/наличие для разных витрин из одного каталога), что закрывает частый кейс «один каталог — несколько стран». Минус: порог входа выше — нужен Python/Django-бэкенд разработчик, и глубокая кастомизация ядра (не через Apps, а изменение самой бизнес-логики) требует форка и сопровождения при апдейтах апстрима.

Если у вас в команде только фронтенд/Node-разработчики — Medusa снимает вопрос найма. Если нужен мультиканальный B2B со сложной ценовой политикой и в штате есть Python-разработчики — Saleor экономит месяцы на том, что у него уже реализовано в ядре.

Когда выгоднее какая платформа: сценарии

Берите Medusa, если:

• Команда — JS/TS full-stack, фронтенд уже на Next.js/React.
• Магазин один, канал продаж один (или пара близких по логике).
• Нужна гибкость в кастомной бизнес-логике заказа (свои workflow-шаги — например, нестандартная логика резервирования склада).
• Стартуете быстро и с ограниченным бюджетом на инфраструктуру — 1-2 vCPU / 4 ГБ реально хватает на старте.

Берите Saleor, если:

• Нужна мультиканальность из коробки: разные витрины (регионы, B2B/B2C, маркетплейсы) с одним каталогом.
• В команде есть Python/Django-разработчики или вы готовы их нанять.
• Важна зрелая модель скидок, промо-акций и подписочных продаж без написания этого с нуля.
• Готовы выделить больше ресурсов на сервер и держать в голове Celery как критичный компонент инфраструктуры.

Обе платформы плохо подходят, если у вас классический контентный e-commerce без кастомной логики и хочется решение «поставил — работает»: для такого случая часто выгоднее WooCommerce или OpenCart на LEMP-стеке — это дешевле по CPU/RAM и по времени найма специалиста. Сравнение готовых движков у нас есть здесь: лучший VPS для интернет-магазина в России, а по установке классики — WooCommerce: установка и настройка.

Продакшен-чеклист: медиа, поиск, бекапы

Обе платформы не решают за вас три эксплуатационных вопроса:

Хранилище медиа. По умолчанию файлы товаров пишутся на локальный диск — плохая идея при нескольких инстансах или при росте каталога. Разумный вариант — S3-совместимое объектное хранилище (MinIO на своём сервере или внешний провайдер), подключаемое через файловый модуль в Medusa (@medusajs/file-s3) или через django-storages в Saleor. Разворачивание MinIO разобрано здесь: MinIO на Ubuntu 24.04: пошаговая установка.

Поиск по каталогу. Встроенный поиск через PostgreSQL ILIKE/tsvector работает, но на каталоге от нескольких тысяч позиций с фасетным поиском (фильтры по атрибутам, опечатки, релевантность) начинает тормозить. Обе экосистемы штатно интегрируются с внешним поисковым движком — Algolia, Elasticsearch/OpenSearch или более лёгкий Meilisearch. Если решаете, что поставить на свой сервер: Meilisearch или Typesense: что выгоднее и когда.

Бекапы. PostgreSQL с данными о заказах и платежах — это то, что нельзя терять. Настройте pg_dump по расписанию с ротацией и вынесите копии за пределы сервера (в тот же MinIO или в отдельное хранилище) до первого продакшен-заказа, а не после инцидента.

Частые вопросы