Adobe Commerce vs Magento Open Source: o comparativo definitivo para decidir

Mesma base de código, três nomes: desfazendo a confusão

Antes de comparar recursos, é preciso acertar a nomenclatura — porque metade das discussões erradas que eu vejo nasce de gente comparando coisas com nomes trocados. Existem hoje três produtos no guarda-chuva, e o nome antigo ainda circula:

Pontos que eu sempre esclareço com cliente:

• "Magento Commerce" é nome morto: era como se chamava o Adobe Commerce antes do rebranding. Se você vê "Magento Commerce" num material, é Adobe Commerce.
• "Magento Enterprise Edition" também é antigo: era o nome na era Magento 1 / início do Magento 2. Hoje, o metapacote enterprise se chama magento/product-enterprise-edition, mas o produto é Adobe Commerce.
• Adobe Commerce ≠ obrigatoriamente cloud: dá para licenciar Adobe Commerce e rodar na sua própria infraestrutura (on-premise). O Cloud é uma opção de hospedagem gerenciada, não o produto em si.
• Mage-OS / OpenMage: forks comunitários do Open Source. Fora do escopo deste comparativo, mas valem citar para quem quer só a base aberta com governança independente.

A consequência prática dessa base comum é enorme: um módulo, um tema e a maioria das extensões de mercado funcionam nas duas edições. Quando você desenvolve em cima do framework — observers, plugins, service contracts, GraphQL — está escrevendo o mesmo código nas duas — os mesmos padrões que detalho no guia de desenvolvimento de módulos no Magento 2. É por isso que migrar de Open Source para Adobe Commerce é, em geral, uma troca de metapacote e ativação de módulos, não um replatforming.

O que é exclusivo do Adobe Commerce (e a doc oficial confirma)

Aqui está o cerne da decisão. Vários recursos do Adobe Commerce trazem, na própria documentação do Experience League, um aviso explícito de exclusividade. Não é interpretação minha — é o texto literal da Adobe em cada página:

This is an exclusive feature that is available only in Adobe Commerce and is not available in Magento Open Source.

Fonte: Adobe Experience League (Content Staging)

Esse mesmo aviso aparece, palavra por palavra, em Reward Points, Store Credit, Visual Merchandiser e em vários outros. Aqui está o mapa que eu uso para decidir:

Visual Merchandiser e merchandising por regra

É um dos recursos que mais converte argumento em venda: em vez de arrastar produto a produto na categoria, você define regras ("mais vendidos primeiro", "sem estoque por último", "maior margem no topo") e a categoria se reordena sozinha. A doc é explícita sobre a exclusividade:

This is an exclusive feature that is available only in Adobe Commerce and is not available in Magento Open Source.

Fonte: Adobe Experience League (Visual Merchandiser)

O custo de "recriar no Open Source"

Quase tudo dessa lista existe como módulo de terceiro para Open Source. O que eu vejo na prática: módulos de loyalty, store credit e gift card de marketplace cobrem o caso simples, mas B2B e RMA são onde a recriação fica cara e frágil. Hierarquia de empresas, aprovação de purchase order, shared catalog com preço por empresa — isso é regra de negócio profunda que, feita por terceiro, vira dívida técnica e ponto de falha em todo upgrade. Quando o B2B é o core do negócio, eu paro de discutir e recomendo Adobe Commerce.

B2B na prática: os pacotes, versões e módulos reais

O B2B é, na minha experiência, o recurso que sozinho justifica o Adobe Commerce para a maioria dos clientes que migram de um ERP-cêntrico para venda online. Vale entender que ele não vem "ligado" — é um pacote separado, instalado via Composer, em cima de uma licença Adobe Commerce ativa.

# instalar o módulo B2B (requer licença Adobe Commerce)
composer require magento/extension-b2b
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

# habilitar funcionalidades B2B no admin:
# Stores > Configuration > General > B2B Features

A versão mais recente confirmada na doc é a 1.5.3, compatível com Adobe Commerce 2.4.8 e 2.4.9, com um pacote de segurança associado (magento/security-package-b2b 1.0.7). Por baixo do magento/extension-b2b vêm os módulos internos:

O que cada peça resolve no mundo real

• Company Accounts: a empresa compradora tem vários usuários com papéis e permissões (comprador, aprovador, admin da conta), com hierarquia. Resolve o caso "o estagiário monta o pedido, o gerente aprova".
• Shared Catalogs: cada empresa (ou tier) enxerga um catálogo e uma tabela de preços próprios. Resolve preço negociado por cliente sem expor para o resto do mercado.
• Negotiable Quotes: o cliente monta o carrinho e pede cotação; o vendedor ajusta preço/frete e devolve. Resolve a negociação que hoje vive no WhatsApp e no e-mail.
• Requisition Lists e Quick Order por SKU: recompra de uma lista fixa de SKUs sem navegar o catálogo. Resolve o B2B de reposição recorrente.

O Adobe Commerce B2B inclui contas de empresa com hierarquia de usuários e papéis, catálogos compartilhados com preços por empresa, cotações negociáveis, ordens de compra com fluxo de aprovação e listas de requisição — recursos não disponíveis nativamente no Magento Open Source. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League (B2B Guide Overview)

Quem opera B2B no Brasil sabe que o gargalo real é a integração com ERP e a emissão fiscal — e isso vale para as duas edições. Vale ler em paralelo o guia de integração Magento 2 com ERP e NF-e, porque company accounts e shared catalogs só fazem sentido quando os preços e o estoque batem com o ERP.

Page Builder e CMS: o que virou comum às duas edições

Aqui está a maior atualização que muita gente perdeu e ainda repete errado em 2026: Page Builder não é mais exclusivo do Adobe Commerce. Ele passou a ser empacotado no Magento Open Source a partir do 2.4.3 (agosto de 2021), e desde então é a ferramenta padrão de edição de conteúdo nas duas edições. A doc é literal:

Starting with the 2.4.3 release, Page Builder is now available as a bundled extension in Magento Open Source. It is now the default content-editing tool for both Adobe Commerce and Magento Open Source, and can replace the WYSIWG editor with any third-party module.

Fonte: Adobe Experience League (Page Builder Release Notes)

Antes do 2.4.3, Page Builder era um diferencial enterprise — e muito material antigo (inclusive comparativos de blog que ainda rankeiam no Google) lista Page Builder como "exclusivo do Commerce". Está desatualizado. Hoje, no Open Source, você tem o mesmo editor visual de arrastar-e-soltar para páginas CMS, blocos e atributos de produto.

Onde o CMS ainda separa as edições

O editor é o mesmo, mas o que você faz com o conteúdo muda. O que continua exclusivo do Adobe Commerce é o Content Staging & Preview: criar uma versão do conteúdo, agendar uma janela (início/fim) e pré-visualizar como a loja ficará naquela data — para produtos, categorias, páginas CMS, blocos e até regras de preço de catálogo/carrinho.

Na prática: se sua operação faz campanhas datadas pesadas (Black Friday com preços que viram à meia-noite, troca de banner e regra de carrinho sincronizada), o Content Staging do Adobe Commerce economiza muito risco operacional — você agenda tudo e pré-visualiza, em vez de subir mudanças manualmente na virada do dia. No Open Source, dá para resolver com regras de preço com data de início/fim e cron, mas sem o preview e sem o agrupamento de mudanças numa "campanha" única.

Serviços com IA: Live Search e Product Recommendations

A Adobe entrega busca e recomendação como serviços SaaS separados (rodam na nuvem da Adobe, não no seu servidor), instalados como extensão. Aqui há uma distinção importante que muda a decisão, então vou ser preciso sobre o que exige licença Adobe Commerce e o que não exige.

Live Search: exclusivo do Adobe Commerce

O Live Search (busca com merchandising e IA via Adobe Sensei) é entregue como serviço, mas requer Adobe Commerce 2.4.4+ e chaves de API vinculadas a uma licença ativa do Adobe Commerce. Ele não é compatível com Magento Open Source. Ou seja: vem incluído na licença do Commerce, mas não é uma opção para quem está no Open Source.

A página de instalação do Live Search lista como requisito Adobe Commerce 2.4.4 ou superior (nas modalidades on Cloud e on-premise), e exige chaves de API geradas pela conta do detentor da licença do Commerce — o produto não é compatível com o Magento Open Source. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League (Live Search)

Product Recommendations: disponível para as duas edições

Já o Product Recommendations (também powered by Adobe Sensei) está documentado como disponível para ambas as edições — Adobe Commerce e Magento Open Source — como serviço SaaS instalável separadamente. É o cenário em que uma loja Open Source consegue, sim, usar um serviço de IA da Adobe.

# Product Recommendations é uma extensão de serviço (SaaS)
composer require magento/module-product-recommendations
bin/magento setup:upgrade
bin/magento cache:flush

# depois: gerar API keys no Commerce Services Connector
# e configurar em Stores > Configuration > Services

Ressalva honesta: mesmo serviços documentados para as duas edições exigem registro no Commerce Services Connector e geração de API keys; vale validar na sua conta se o tier de chave que você consegue cobre o uso pretendido, porque a Adobe ajusta requisitos com o tempo.

Quer ativar e operar esses serviços na prática? Eu detalho a instalação, as API keys, os tipos de recomendação do Adobe Sensei e os cuidados de LGPD no guia IA no Magento e Adobe Commerce. E se o seu interesse é usar IA para programar em cima do Magento, veja IA no desenvolvimento Magento.

Analytics: Advanced Reporting vs Commerce Intelligence

Outra fonte de confusão. Existem dois produtos de analytics com nomes parecidos, e só um deles está no painel das duas edições sem custo extra.

Advanced Reporting (as duas edições, grátis)

O Advanced Reporting é a funcionalidade básica de relatórios, disponível para Open Source e Adobe Commerce sem custo adicional. Ele já entrega dashboards de pedidos, produtos e clientes direto no admin, alimentado por um serviço da Adobe. Para a maioria das lojas pequenas e médias, isso resolve o operacional.

Commerce Intelligence / MBI (separado, mais profundo)

O Commerce Intelligence (antigo Magento Business Intelligence, MBI) é uma plataforma de analytics separada, que após ativação inclui cinco dashboards com cerca de 70 relatórios. É um produto à parte — requer ativação e, dependendo do plano, faz parte do pacote Adobe Commerce ou é contratado separadamente. É onde você cruza coorte, LTV, retenção e margem de verdade, não só "vendas do mês".

O Commerce Intelligence (antiga plataforma Magento Business Intelligence) é uma solução de analytics separada que, após ativação, disponibiliza um conjunto de dashboards com dezenas de relatórios pré-construídos; já o Advanced Reporting básico está disponível nas duas edições. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League (Commerce Intelligence / MBI)

Minha leitura: para decidir entre edições, analytics raramente é o fator decisivo — porque ferramentas externas (GA4, Looker, Metabase sobre uma réplica do banco) cobrem a necessidade nas duas. O que pesa mais é B2B, Cloud e suporte.

Adobe Commerce on Cloud: a infra gerenciada por dentro

O Adobe Commerce on Cloud é o PaaS gerenciado da Adobe — o mesmo Adobe Commerce, mas com a infraestrutura, o deploy e várias ferramentas de performance embutidas. É aqui que muita gente confunde "comprei Adobe Commerce" com "estou no Cloud". São coisas separadas: você pode ter Adobe Commerce on-premise. O Cloud é a hospedagem gerenciada.

Três ambientes, sempre

A arquitetura padrão tem três tipos de ambiente, e isso disciplina o seu fluxo de deploy:

Fastly: CDN, Varnish e WAF na borda

O Fastly é obrigatório nos ambientes Staging e Production, entregando CDN, cache Varnish e WAF (Web Application Firewall). Detalhe operacional importante: o WAF existe apenas em Production. O Fastly é também onde você gerencia regras de cache, image optimization e regras de borda. Para quem vem do on-premise montando Varnish na mão, é uma camada inteira de trabalho que sai da sua responsabilidade.

A documentação de arquitetura do Adobe Commerce on Cloud descreve três ambientes (Integration, Staging e Production); o Fastly provê CDN, cache e WAF nos ambientes de Staging e Production, com o WAF disponível apenas em produção; o plano Pro adota arquitetura de alta disponibilidade com três nós em produção. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League (Cloud Architecture)

Observabilidade: New Relic incluído, Blackfire não

O New Relic APM vem incluído nos projetos Cloud, e o plano Pro adiciona o New Relic Infrastructure (NRI) para monitorar os servidores de staging e produção. Uma correção que sempre faço: Blackfire NÃO está mais incluído por padrão — hoje, para profiling com Blackfire, você precisa de uma licença direta com a Blackfire. Material antigo ainda diz que vem de fábrica; não vem.

# fluxo de deploy típico no Cloud (Git-based, via ECE-Tools)
git push origin minha-feature      # dispara build no ambiente Integration

# config de build/deploy vive em arquivos versionados:
#   .magento.app.yaml       (serviços, hooks, mounts)
#   .magento/services.yaml  (mysql/mariadb, redis, opensearch...)
#   .magento.env.yaml       (variáveis de build e deploy)

# o deploy roda os hooks de build (di:compile, scd) e deploy (setup:upgrade)
# automaticamente — você não toca em SSH para subir código

O ganho de performance do Cloud não é mágica: é Fastly na frente, infra dimensionada e SCD on build. Mesmo assim, otimização de aplicação continua sendo sua — full page cache, índices, imagens, JS de terceiro. Tudo que está no guia de performance e Core Web Vitals no Magento 2 vale igual no Cloud; o Cloud te dá a borda, mas não conserta um tema pesado.

Licença e custo: o modelo por GMV, sem inventar número

Essa é a parte onde mais se mente na internet, então vou ser rigoroso sobre o que é fato e o que é estimativa de terceiro.

O que é fato

• Magento Open Source: não tem custo de licença. Zero. Você paga em infraestrutura, desenvolvimento, manutenção e suporte — que não são pouco, mas não há mensalidade para a Adobe.
• Adobe Commerce: a licença é baseada em GMV (Gross Merchandise Value) anual — o volume bruto de mercadoria que passa pela loja. Não há preço público fixo. Cada contrato é negociado diretamente com o time de vendas da Adobe, e o valor escala conforme a faixa de faturamento.
• Adobe Commerce on Cloud: soma o custo de infra gerenciada à licença, também na conversa comercial.

O que é estimativa de mercado (não oficial)

Existem estimativas circulando de que a licença começaria em torno de US$ 22.000/ano para GMV abaixo de US$ 1M, subindo por faixas. Eu cito isso explicitamente como dado de mercado de terceiros, não confirmado pela Adobe — a Adobe não publica tabela. Use como ordem de grandeza para a conversa interna, jamais como número de proposta. Quem te der um "preço de tabela do Adobe Commerce" com precisão está chutando.

O TCO real, na minha experiência

O erro clássico é olhar só a licença. O cálculo honesto é custo total de propriedade (TCO): no Open Source, o que você "economiza" de licença muitas vezes reaparece em horas de desenvolvimento para recriar features, em DevOps para tocar a infra e em risco de não ter SLA quando cai. No Adobe Commerce, você paga a licença mas troca grande parte disso por features prontas e suporte. A conta vira a favor do Commerce normalmente quando: o faturamento é alto o suficiente para que a licença seja uma fração pequena dele, ou quando você precisaria reconstruir B2B/loyalty/staging de qualquer jeito.

Suporte, SLA, segurança e o ecossistema Adobe

Recurso de produto é o que se vê no slide. O que decide na hora da crise é quem atende o telefone às 3 da manhã e qual o compromisso contratual.

Suporte e SLA

O Adobe Commerce inclui suporte oficial com SLA — você abre ticket com a Adobe e há compromisso de tempo de resposta conforme severidade. No Magento Open Source, o "suporte" é a comunidade, a documentação e o seu parceiro/agência. Para um e-commerce que fatura alto e não pode ficar fora do ar, a diferença entre "tem SLA" e "depende de quem você contratou" é material. Eu sempre pergunto ao cliente: quanto custa uma hora de loja fora do ar? A resposta costuma reposicionar a conversa de licença.

Segurança: a base é a mesma, o processo muda

Em segurança de código, as duas edições recebem os mesmos boletins APSB e os mesmos patches de núcleo — porque o núcleo é o mesmo. A diferença está no processo e nas ferramentas em volta: no Cloud, o WAF Fastly em produção é uma camada que o on-premise precisa montar sozinho; o Adobe Commerce também traz recursos como Action Logs (auditoria de admin) que o Open Source não tem nativo. Independente da edição, hardening é responsabilidade sua — todo o processo de patch, 2FA, CSP e rotação de chave que detalho no guia de segurança e hardening do Magento 2 se aplica aos dois.

O ecossistema Adobe Experience Cloud

Esse é o argumento que muda o jogo para grandes marcas: o Adobe Commerce conversa nativamente com o resto do Adobe Experience Cloud — Adobe Analytics, Adobe Target (testes A/B e personalização), Adobe Experience Manager (AEM, gestão de conteúdo/DAM) e a Adobe Experience Platform (CDP). Se a empresa já investiu na stack Adobe de marketing, ter o e-commerce na mesma família reduz atrito de integração de dados e identidade do cliente. Para quem não usa nada disso, esse ecossistema é um diferencial que você não vai aproveitar — e não deve entrar na conta da decisão.

A virada SaaS: Adobe Commerce as a Cloud Service e Optimizer

Vou tratar este tema com a cautela que ele merece, porque é roadmap e há muito ruído. O que dá para afirmar com fonte oficial, eu afirmo; o resto, sinalizo como anúncio.

Adobe Commerce as a Cloud Service (ACCS)

A Adobe anunciou o Adobe Commerce as a Cloud Service, um novo modelo SaaS. A diferença filosófica em relação ao PaaS atual: a Adobe assume a responsabilidade total pela aplicação central, pela infraestrutura e pelas atualizações, num modelo versionless (sem "sua versão" para manter) com atualizações contínuas, arquitetura API-first e storefronts headless via Edge Delivery Services. A documentação de migração descreve o produto como:

Adobe Commerce as a Cloud Service represents a significant shift to a fully managed, versionless SaaS model, offering enhanced performance, scalability, simplified operations, and tighter integration with the broader Adobe Experience Cloud.

Fonte: Adobe Experience League (ACCS Migration Overview)

O que isso muda no longo prazo: no SaaS, você para de gerenciar versão, patch e infra do núcleo — a Adobe faz. O contraponto é menos controle sobre o core e um modelo de customização mais orientado a serviços e extensões do que a sobrescrever código. A migração do PaaS para o SaaS já tem documentação de overview publicada.

Adobe Commerce Optimizer

Junto ao ACCS, a Adobe anunciou o Adobe Commerce Optimizer, descrito como uma forma de aplicar capacidades de performance e merchandising com IA a storefronts existentes sem um replatforming completo. Status: trato como anúncio de roadmap, não como disponibilidade geral confirmada — não consegui validar uma URL oficial específica do produto, então não afirmo detalhes de funcionamento para cliente.

O que eu digo para cliente hoje

• Não congele decisão por causa de roadmap: se você precisa lançar agora, escolha entre Open Source e Adobe Commerce (PaaS/on-prem) com base no que existe e é estável hoje.
• Construa headless-friendly: a direção da Adobe é claramente API-first e headless. Investir agora em arquitetura desacoplada (GraphQL, storefront separado) reduz o atrito de qualquer migração futura para SaaS.
• Confirme disponibilidade direto com a Adobe: antes de prometer ACCS a um cliente, valide GA (general availability) na sua região e para o seu caso com o time Adobe. Roadmap não é contrato.

Como escolher: a matriz de decisão que eu uso

Depois de tudo, a decisão vira alguns critérios objetivos. Esta é a matriz que eu aplico em projeto real, sem viés de quem vende licença:

Três perguntas que resolvem 90% dos casos

• 1. B2B é central? Se sim, Adobe Commerce quase sempre vence — o pacote B2B sozinho justifica.
• 2. Quanto custa uma hora de loja fora do ar? Se a resposta assusta, você está comprando SLA, não só software — e isso aponta para Adobe Commerce/Cloud.
• 3. A licença é que fração do faturamento? Se for uma fração pequena e você usaria os recursos, ela se paga. Se for um peso grande e você usaria 5% das features, fique no Open Source.

O caminho de migração não é uma armadilha

Boa notícia que tira pressão da decisão: como a base de código é a mesma, começar no Open Source e migrar para Adobe Commerce depois é viável — em geral é trocar o metapacote (magento/product-community-edition → magento/product-enterprise-edition), licenciar e ativar os módulos. Não é replatforming. Então, na dúvida e com orçamento apertado, eu não tenho medo de recomendar começar no Open Source bem arquitetado e migrar quando o B2B ou o volume justificarem. O que não vale é o caminho inverso barato: voltar de Commerce para Open Source significa perder os dados das features exclusivas. E quem está preso no Magento 1 em fim de vida deve tratar a migração para o 2 (em qualquer edição) como prioridade, e aí decidir a edição com esta matriz.