Magento has a reputation for being demanding. It is deserved, but the reason is usually misunderstood. It is not simply that Magento is bigger than other shopping carts. It is that Magento expects a set of supporting services around it, and does a great deal of work in the background that other carts do at the moment of the request. Hosting it on a plan sized for a brochure site does not produce a slightly slower shop. It produces a shop that behaves strangely.
Most PHP applications need PHP and a database, and that is the end of the list. Magento expects considerably more than that: a search engine for catalogue search and layered navigation, a separate cache backend, a message queue for asynchronous work, and Composer for managing the code itself.
Adobe is unusually strict about this. The published system requirements list specific tested combinations of PHP, MariaDB or MySQL, the search engine, the message queue and the cache backend, and Adobe states plainly that it supports only those combinations and does not validate anything else. This is worth taking seriously when you plan an upgrade, because it means the version of Magento you want may require you to move the database or search engine version first, in a particular order.
The practical consequence for hosting is simple: a plan that offers PHP and MySQL and nothing else is not a Magento plan, whatever its resource limits say.
A great deal of what makes Magento fast for a shopper is precomputed. Prices, catalogue rules, stock and the search index are all built ahead of time by indexers, and those indexers are driven by cron. If cron is not running, or is running but failing, the site does not usually stop. It goes quietly wrong: prices do not update after you change them, new products do not appear in search, stock levels drift, and scheduled promotions do not start.
This is the single most common Magento problem we are asked about, and it is almost always cron. Any hosting that does not let you run proper scheduled tasks, or that kills long running processes aggressively, will produce exactly these symptoms.
The same applies to the message queue. Magento pushes work onto it that is not needed to answer the current request, and consumers process that work in the background. If nothing is consuming the queue, the work simply does not happen.
Magento is designed on the assumption that a full page cache is in front of it, and that a separate cache backend is holding configuration, blocks and other frequently read data. Running with caching disabled, which is the state a site is often left in after development work, is enormously slower and is not a reasonable production configuration.
It is worth being clear that the parts of a shop that matter most cannot be cached in the same way. A basket, a checkout, a customer account page and live stock are different for every visitor and have to be generated fresh. That is why raw processing capacity and database performance matter for a shop in a way they do not for a content site, and why “we cache everything so hardware does not matter” is not true for e-commerce.
Magento in production is not a site you edit over FTP. Code is managed with Composer, static content is compiled and deployed as a build step, and dependency injection configuration is compiled too. There is a maintenance mode for the period while that happens.
This is a genuine operational difference from WordPress or CubeCart, where uploading a changed file is a normal thing to do. It also means your hosting needs command line access, a sensible amount of memory available to the command line PHP process, and enough disk space to hold generated content that can be substantial.
That is a fair question and the honest answer is that it depends on the size of the catalogue and the complexity of the business rules. Magento earns its overhead on large catalogues, multiple stores, multiple currencies and complicated pricing. For a store with a few hundred products and straightforward pricing, a lighter cart will cost less to host, less to maintain and less to upgrade, and will not be slower in any way the customer notices.
We host both. Tell us what you are running and we will say which one fits. If you are weighing this up, or you have an existing Magento store that is behaving oddly, get in touch and we will look at it with you.