What limits do Atlas shared tiers M0, M2 and M5 impose compared with a dedicated cluster?
answer
- Two halves to the tier ladder
- Shared hosts mean shared CPU and RAM
- Storage caps: 512 MB on the free tier
- Some features missing entirely, not just smaller
- Sharding, auto-scaling, multi-region need dedicated
basics
~20 sAtlas shared tiers run on multi-tenant hosts with capped storage (M0 gives 512 MB), throttled throughput and connections, and no dedicated CPU or RAM. Sharding, auto-scaling, multi-region node placement and private networking all require a dedicated M10 or larger cluster.
solid answer
~50 sM0, M2 and M5 are **shared** tiers: your cluster is one tenant on a host you do not own, so CPU and RAM are shared and throughput is deliberately throttled. Storage is small and fixed — 512 MB on the free M0, 2 GB on M2, 5 GB on M5 — and the number of collections and concurrent connections is capped. Beyond capacity, whole capability classes are simply absent: no sharding, no cluster-tier or storage auto-scaling, no multi-region or multi-cloud node distribution, no private-network connectivity, and no customer-managed encryption keys. M0 also has no cloud backups. Dedicated tiers start at M10, where you get an isolated instance with a known RAM and CPU allocation, so performance becomes predictable and you can size against a real working set. Treat shared tiers as prototyping, demos and teaching — not as a small production deployment you plan to grow.
go deeper
Be ready to name the three shared tiers, say that M0 is free with 512 MB of storage, and state that CPU and RAM are shared rather than dedicated.
Explain why shared hosting removes performance predictability, and list the capability cliffs — sharding, auto-scaling, multi-region nodes and private networking all start at dedicated tiers.
Show judgment about when a workload has outgrown a shared tier for a non-capacity reason, and treat the upgrade as a migration with a window and a connection-string check rather than a slider move.
Own the policy: which environments are allowed on free or entry tiers, what the cost and compliance boundary is, and how teams are stopped from quietly running production on a tier with no backups.
## The tier ladder Atlas sells a MongoDB replica set as a **cluster tier** — a named size such as M0, M2, M5, M10, M30, M60. The letter-number is not just a price point; it selects a class of hardware and, crucially, a set of capabilities. The ladder splits into two halves. M0/M2/M5 are **shared** tiers: many customers' clusters live on the same underlying machines and are isolated by resource limits rather than by dedicated hardware. M10 and above are **dedicated** tiers: your replica set gets its own instances with a published amount of RAM, vCPU and disk. ## What the shared tiers give you M0 is the free tier. It provides a three-node replica set with 512 MB of storage, available in a subset of regions on AWS, Google Cloud and Azure, and Atlas allows one free cluster per project. M2 and M5 are the paid shared tiers, offering 2 GB and 5 GB of storage respectively plus cloud backups. All three run genuine MongoDB with the same query language, aggregation framework, indexes and drivers — which is exactly why they are excellent for learning, prototypes, demos and CI fixtures. ## What they take away The limits fall into three buckets. **Resource limits.** Storage is a hard cap, not a soft one — you will hit it and writes will start failing. CPU and memory are shared with other tenants, so a neighbour's load can affect your latency, and Atlas throttles operations per second and caps concurrent connections. Because there is no guaranteed RAM, there is no meaningful notion of "my working set fits in cache", which is the single most important performance property of a MongoDB deployment. **Capability limits.** Several features are only available from M10 up: cluster tier and storage auto-scaling, multi-region and multi-cloud node placement, read-only and analytics nodes, private-network connectivity, and customer-managed encryption keys. Sharding is further up still — a sharded cluster requires M30 or larger. Atlas Search is available on shared tiers but with a small fixed number of search indexes. M0 has no cloud backup at all. **Operational limits.** The number of collections is capped, so a multi-tenant "collection per customer" design dies immediately on a shared tier. Performance tooling is reduced. And because the host is shared, the metrics you see are less useful for capacity planning: you cannot reason about CPU steal or cache pressure on hardware you do not own. ## Why the boundary matters in an interview The question is really "do you know where free stops being viable?". The wrong answer is "M0 is just a small M10". The right answer identifies the **discontinuities**: predictability of performance, the availability of scaling and resilience features, and the private-networking and encryption controls that most production security reviews require. A workload can outgrow a shared tier for any one of those reasons independently of data volume — a 100 MB dataset that must sit behind a private endpoint already needs M10. ## Planning the move off a shared tier Going from a shared tier to a dedicated one is not the same kind of change as resizing M10 to M20. Treat it as a migration: schedule a window, verify the connection string your application uses after the change rather than assuming it is untouched, re-check that your driver reconnects cleanly, and confirm the features you were waiting for (backups, private networking, auto-scaling) are actually configured afterwards rather than assuming they arrive by default. ## The Flex consolidation Atlas has been consolidating its entry-level offerings: the **Flex** cluster tier was introduced to replace the M2/M5 shared tiers and serverless instances with a single usage-billed shape, while M0 remains as the free tier. The conceptual split an interviewer cares about — shared, multi-tenant, capability-restricted versus dedicated, isolated, fully featured — is unchanged, but if you are quoting today's catalogue, say which offering you mean and check the current Atlas pricing page rather than reciting tier names from memory. ## A useful rule of thumb Use M0 for anything you would be happy to lose. Use a paid entry tier for a low-traffic internal tool where an occasional latency spike is tolerable. Use M10 or above the moment the answer to "what happens if this is slow or unavailable for ten minutes?" stops being "nothing".
- Which Atlas cluster tier do you need before you can shard a collection?Sharded clusters require a dedicated tier of M30 or larger. Below that Atlas only offers replica-set clusters, so the answer to a capacity problem on M10 or M20 is to scale the tier up first; sharding becomes an option only once you are already on M30-class hardware. That is one reason shard-key design conversations rarely start on entry tiers.
- Why is a shared tier a poor place to benchmark a query?Because you do not control CPU, memory or IOPS. Your cache hit rate depends on RAM you were never allocated, and a co-tenant's activity plus Atlas's own throttling can dominate the timings. Numbers from a shared tier tell you whether a query is logically correct and roughly how many documents it examines, not how it will perform on production hardware.
- If your dataset is tiny, is there ever a reason to still pay for M10?Yes. Data size is only one axis. Private-network connectivity, customer-managed encryption keys, multi-region node placement, auto-scaling, point-in-time restore and predictable latency all begin at dedicated tiers. A 50 MB dataset that must sit behind a private endpoint or survive a region failure needs M10 or above regardless of how little it stores.
saying these in an interview costs you the question
- Calling M0 just a smaller version of M10
- Claiming shared tiers support sharding or auto-scaling
- Assuming free tier storage grows if you pay overage
- Benchmarking on M0 and quoting the latency as production
- Believing every Atlas feature works on every tier