Running several stores on one Magento is efficient. One codebase, one admin, one catalogue to maintain. It is also where a performance problem in one store becomes a performance problem in all of them, and that surprises people.
The cache multiplies
Full page cache stores a version per store view. Three storefronts in four languages is twelve versions of every page, and that is before you count currency or customer group.
The consequence is straightforward: a cache that comfortably held one store may hold a fraction of twelve. Hit rates fall, more requests are rendered live, and the whole installation feels slower even though nothing changed in the code.
The database does not know about your stores
Every store view shares the same tables. A large catalogue import for one storefront locks tables that the others read from. A heavy report in one admin affects everyone.
That is manageable, but only if you plan around it: schedule per installation rather than per store, and stagger the work that is heavy.
Indexing across store views
Indexers run per store view for the things that vary per store, which usually means prices and catalogue visibility. More store views means more index work for the same catalogue change.
On a large multistore this becomes the dominant cost of any catalogue update, and it is the reason update by schedule stops being a recommendation and becomes a requirement.
When to split
Occasionally the honest answer is that these stores should not share an installation. The signs are consistent:
- The catalogues have little in common, so the shared structure buys you nothing.
- One store is far larger than the others and dictates every scheduling decision.
- Release cycles conflict, so nobody can deploy without coordinating with everyone.
- A problem in one storefront has taken the others offline more than once.
Splitting costs money and removes the efficiency you built the multistore for, so it is not a first move. But if three of those four apply, the shared installation is costing more than it saves.