Magento is a modular, PHP-based e-commerce platform for building and running online stores with complex catalogs, multiple storefronts and deep integrations. Among store platforms in e-commerce, it occupies the enterprise and upper mid-market segment: it offers far more architectural control than hosted services, at the cost of substantially higher engineering and hosting effort.
Today the platform exists in two editions. Magento Open Source is the free, self-hosted codebase, and Adobe Commerce is the commercial edition with additional business features, support and an optional managed cloud infrastructure. Both share the Magento 2 core architecture, which replaced the original Magento 1 line after that version reached end of life in 2020.
How the Magento architecture works
Magento is built as a collection of modules on top of a shared framework, where each module encapsulates one business capability such as catalog, checkout, customer accounts or tax calculation. Modules are installed and updated through Composer, the PHP dependency manager, and declare their dependencies explicitly.
Customization relies on extension points rather than core edits. Dependency injection lets a developer replace or wrap classes through configuration, plugins (interceptors) run code before, after or around public methods, and observers react to dispatched events. Because the core stays untouched, upgrades remain possible, although heavily customized stores still require careful regression testing.
The data layer combines a relational database with an entity-attribute-value (EAV) model for products, categories and customers. EAV allows merchants to add attributes without schema changes, but it makes raw queries slow, so Magento maintains indexers that flatten data into fast lookup tables. The table below lists the main runtime components of a typical production installation.
| Component | Typical technology | Role in the store |
|---|---|---|
| Application | PHP 8.x with Composer modules | Business logic, admin panel and storefront rendering |
| Database | MySQL or MariaDB | Orders, customers, configuration and EAV data |
| Search engine | OpenSearch or Elasticsearch | Catalog search, layered navigation and filtering |
| Full-page cache | Varnish or built-in cache | Serving rendered pages without executing PHP |
| Session and object cache | Redis or Valkey | Fast storage for sessions and configuration cache |
| Message queue | RabbitMQ or MySQL queue | Asynchronous tasks such as bulk updates and exports |
Store hierarchy and catalog flexibility
A distinctive feature of Magento is its three-level scope hierarchy: a single installation contains websites, each website contains stores with their own root category, and each store contains store views that usually represent languages. Prices, payment methods, stock and content can be configured at different levels of this hierarchy.
This structure lets one back office run several brands, countries and languages from one catalog. The catalog itself supports six native product types, which cover most retail scenarios without extensions.
| Product type | What it represents | Typical use |
|---|---|---|
| Simple | One physical item with one SKU | A single book or a mug |
| Configurable | Parent with selectable child variants | A shirt sold in sizes and colors |
| Grouped | Set of simple products sold separately | A furniture series on one page |
| Bundle | Customer-built kit from options | A computer assembled from components |
| Virtual | Non-physical item without shipping | A warranty extension or a service |
| Downloadable | Digital file delivered after purchase | Software, music or e-books |
Adobe Commerce adds business-to-business functions such as company accounts, shared catalogs with negotiated prices, quick order forms and quote requests. These features explain why the platform is common among manufacturers and distributors that sell to both consumers and trade buyers.
Magento compared with other store platforms
Magento differs from its neighbors mainly in who operates the infrastructure and how far the platform can be reshaped. Shopify is a hosted software service, WooCommerce is a plugin for WordPress, and PrestaShop is a lighter self-hosted PHP platform. The comparison below summarizes the practical differences.
| Platform | Hosting model | Customization depth | Typical operating effort |
|---|---|---|---|
| Magento Open Source | Self-hosted | Very high, full code access | Dedicated developers and DevOps |
| Adobe Commerce | Self-hosted or managed cloud | Very high plus B2B features | Agency or in-house team, license fees |
| Shopify | Hosted software service | Moderate, through apps and APIs | Low, platform handles operations |
| WooCommerce | Self-hosted WordPress plugin | High within WordPress limits | Low to moderate for small stores |
| PrestaShop | Self-hosted | High, lighter codebase | Moderate, smaller hosting needs |
Magento can also serve as the back end of a headless commerce setup. Its GraphQL and REST APIs expose catalog, cart and checkout operations, so a separate front end built with a JavaScript framework can replace the classic theme while Magento keeps handling pricing, inventory and orders.
Choosing and running Magento in practice
Magento is a strong fit when requirements are complex and a weak fit when they are simple. The decisive questions concern catalog size, the number of storefronts, B2B logic and the availability of skilled developers. The decision table below translates typical situations into recommendations.
| Situation | Recommendation | Reason |
|---|---|---|
| Tens of thousands of SKUs with rich attributes | Magento is suitable | EAV and indexers handle large, varied catalogs |
| Several brands or countries from one back office | Magento is suitable | Website and store view scopes are built in |
| Small shop with a few hundred products | Prefer a hosted platform | Operating cost outweighs the flexibility |
| Complex B2B pricing and company accounts | Consider Adobe Commerce | B2B module avoids custom development |
| No access to PHP developers | Avoid self-hosted Magento | Updates and security patches need expertise |
Front-end performance depends heavily on the theme. The default Luma theme relies on older JavaScript libraries and is often slow on mobile devices, so many projects adopt lighter alternative themes or a headless front end. On the server side, Varnish full-page caching, Redis and a correctly configured search engine are considered baseline requirements rather than optional tuning.
Limitations and common mistakes
The most frequent problem is underestimating total cost of ownership. License fees may be zero for Open Source, but hosting, extension licenses, development, testing and regular security patch releases create a recurring budget that often exceeds that of hosted platforms.
- Installing too many third-party extensions increases conflicts between plugins and slows upgrades.
- Running indexers on save in a large catalog causes slow admin operations; scheduled indexing through cron is usually preferable.
- Skipping security patches exposes stores to payment-skimming attacks, which have repeatedly targeted outdated installations.
- Editing core files instead of using plugins and preferences breaks the upgrade path.
- Shared hosting rarely meets the memory, search engine and cache requirements of a production store.
The simple explanation
Magento is software for running an online shop, built for businesses whose needs are too complicated for simple store builders. It can manage many brands, languages and countries from one place, and it can handle very large product ranges.
Think of it as a professional workshop rather than a ready-made shop. Everything can be adjusted, but someone skilled has to set it up, maintain it and keep it secure. The flexibility is the main benefit, and the effort is the main cost.
How it is used in practice
A European manufacturer of garden tools sells to consumers in four countries and to about 600 retail partners. It runs one Magento installation with one website for consumers and one for trade customers, plus four store views for German, French, Italian and English.
Consumers see public prices in their currency, while trade buyers log in to company accounts with negotiated price lists and order by entering SKUs into a quick order form. About 18,000 products share one catalog, and stock updates arrive every 15 minutes from the warehouse system through the REST API.
Because the company employs two in-house developers and works with a hosting partner, it applies quarterly patches and runs Varnish and Redis in production. The result is one back office for both sales channels instead of two separate systems that had to be synchronized by hand.