# Atlas Cluster Topology and Tier Economics > Source-anchored research for Atlas Cluster Topology and Tier Economics. Run status: COMPLETED. Parent: [MongoDB Atlas Cost Optimization](https://llms-explorer.com/tree/mongodb-atlas-cost-optimization/) · 7 facets · 80 facts · page: https://llms-explorer.com/tree/atlas-cluster-topology-and-tier-economics/ ## Definitions - Low-CPU is the cheaper option for memory-heavy, CPU-light workloads: similar RAM and storage at a lower price. Vantage (Jan 2024) says the same. (medium confidence) — [source](https://www.vantage.sh/blog/mongodb-cost-optimization-tips) ## Structure and components - The RAM saving is below the vector-value ratio because the HNSW graph structure is not compressed. Sizing must therefore budget graph memory separately from vector memory. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) ## How it works - Enabling Atlas Search on a cluster adds no fee when mongot is co-located with mongod, but co-located search consumes cluster CPU/RAM, and the docs warn of resource contention between mongod and mongot. The docs position co-located deployment for testing and prototyping. (medium confidence) — [source](https://mongodb.com/docs/atlas/atlas-search/about/deployment-options) - An analytics node tier can be set larger or smaller than the base tier. A tier on the Analytics Tier tab is priced like the same tier on the Base Tier tab, with the price adjusted prorated per node when it differs. Atlas shows the price in the UI at create or edit time. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/) - Setting the analytics tier significantly below the base tier can cause replication lag; the analytics node might fall off the oplog. On Atlas Core, analytics storage size must match the base tab, so a small analytics tier does not shrink storage cost; mixing General and Low-CPU across the tabs disables disk auto-scaling. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/) - An arbiter holds no data and votes in elections, giving two data-bearing members an odd vote count at lower cost. The manual recommends at most one arbiter, warns that PSA sets can suffer performance problems with w:majority when a secondary lags, and warns that PSA shards can lose availability. The manual page covers self-managed sets and does not mention Atlas. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-arbiter/) - When sharding is enabled with dedicated config servers, Atlas adds three config servers billed at a separate rate. Cluster tier and data storage selections do not change that config server cost. The rate itself is not published on the billing page. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - Backup billing for a sharded cluster covers each shard replica set plus the config server replica set. Atlas may retain more than one full snapshot when topology changes (for example when a shard is added), which raises backup storage for a period. Cloud Backup rates on the page are AWS $0.14-$0.19, Azure $0.34-$0.65, Google Cloud $0.08-$0.12 per GB-month. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - A one-shard sharded cluster on M30 was described in a MongoDB Jira ticket (PM-2290) as costing about twice an M30 replica set because of dedicated config servers. Undated and internal, so treat as a rough indicator only. (low confidence) (verified as of 2026-10-18) — [source](https://jira.mongodb.org/browse/COMPASS-6208) - Atlas auto-scaling needs a large enough oplog window: the minimum oplog retention window must be up to 60 seconds times GB of disk configured, and Atlas delays a scaling event until the oplog covers the estimated scaling time. Heavy writes can outrun auto-scaling, so docs advise avoiding high-speed writes when planning to scale up. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/customize-storage/) - On AWS M40+ clusters with fast disk pre-warming, Atlas may temporarily provision a higher-performance volume when replacing or adding a node. That cost lands on the monthly storage line, so storage cost can run above forecast in months with node replacements. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - Full-fidelity vectors remain on disk and are read only for rescoring (binary) or exact (ENN) search. Quantization therefore does not reduce disk use, and the Atlas UI Size metric can look larger because it counts the HNSW graph, quantized vectors and full vectors. The Required Memory metric is the one to use for query-time RAM. (high confidence) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - Enabling automatic quantization is a per-field index-definition setting (quantization: scalar or binary) that triggers an index rebuild and needs no query change. Max dimensions are 8192. Non-float-array values are silently skipped. MongoDB suggests it for collections over about 100,000 vectors. (low confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - Because Atlas keeps full vectors on disk plus a quantized copy in memory, enabling quantization raises total disk need while lowering RAM need. Disk and memory must be sized separately when choosing a tier or search node. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) ## Measurements and reference values - The deployment-options page tells users to move to dedicated Search Nodes once they exceed roughly 2 million documents to index, 10 GB of indexed data, or 10,000 queries in 7 days. (low confidence) (verified as of 2026-10-18) — [source](https://mongodb.com/docs/atlas/atlas-search/about/deployment-options) - Search Nodes run on compute-intensive instances with local SSDs that need about 20% storage overhead, so index size must fit the fixed per-tier disk. Index size depends on field mappings; estimate by indexing 1-2 GB of representative data (example ratio 0.25:1). (medium confidence) — [source](https://mongodb.com/docs/atlas/atlas-search/about/deployment-options) - On the MongoDB pricing page (updated 2026-09-29, AWS us-east-1) high-CPU Search Node prices run from S20 $0.12/hr (4 GB RAM, 2 vCPU, 106 GB) through S50 $0.99/hr to S80 $3.26/hr. Low-CPU S30 is $0.11/hr and storage-optimized S40-S is $0.25/hr. Because of the two-node minimum, the floor is about double the listed S20 rate (about $0.24/hr, roughly $175/month, derived). (medium confidence) (verified as of 2026-09-29) — [source](https://www.mongodb.com/pricing.md) - Search Node price varies by cloud for the same tier name: high-CPU S20 is $0.12/hr on AWS us-east-1, $0.14/hr on Google Cloud us-central1, $0.15/hr on Azure eastus2; S50 is $0.99, $1.15 and $1.27/hr respectively. Storage per tier also differs by cloud (S20: 106, 128, 80 GB). (medium confidence) (verified as of 2026-09-29) — [source](https://www.mongodb.com/pricing.md) - Sizing rule of thumb from MongoDB: about 10 QPS per vCPU (two S20 nodes = 4 vCPU = about 40 QPS); target latency under 100 ms; if adding CPU lowers latency the deployment is underprovisioned; scale out to up to 32 nodes for throughput; consider sharding above roughly 10k inserts/updates per second. These are vendor estimates, not benchmarks. (low confidence) (verified as of 2025-08-12) — [source](https://mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Since 2026-06-30 (GA), multi-region clusters can set a different dedicated Search Node count per region. MongoDB estimates 25-40% lower Search Node spend where secondary regions carry little search traffic. The figure is a vendor estimate. Use it to avoid duplicating full node counts in DR regions. (low confidence) (verified as of 2026-06-30) — [source](https://www.mongodb.com/products/updates/now-ga-asymmetric-per-region-dedicated-search-node-counts) - Public Atlas-on-AWS hourly prices (us-east-1, calculated January 2022): M40 $1.04, M40 Low-CPU $0.77 (~26% less), M50 $2.00, M50 Low-CPU $1.48 (~26% less). Treat as stale; confirm in the Atlas pricing page or calculator. (medium confidence) (verified as of 2022-01-01) — [source](https://www.mongodb.com/mongodb-on-aws/pricing) - MongoDB states that data transfer is under 10% of the bill for most Atlas customers, depending on usage patterns. This is a general statement, not a guarantee for a multi-region or cross-cloud topology. (medium confidence) (verified as of 2026-10-18) — [source](https://mongodb.com/mongodb-on-aws/pricing) - Traffic between cluster nodes (replication of writes, deletes and index builds, plus heartbeats) and traffic between an app in the same region and the cluster is billed on the 'Atlas AWS Data Transfer (Same Region)' line. A MongoDB employee estimated heartbeats at about 6.2 to 6.8 GB/day per replica set, roughly $0.06 to $0.07/day, in a 2020 thread. (low confidence) (verified as of 2020-02-14) — [source](https://www.mongodb.com/community/forums/t/aws-atlas-data-transfer-usage/553) - AWS fixed under-metering of cross-zone NLB data transfer on 2025-05-01. Atlas uses cross-zone NLBs for its AWS PrivateLink endpoint service. MongoDB covered the cost through 2025-05-15, then expected invoices to rise about 1.0% on average, on the 'Atlas AWS Data Transfer (Same Region)' line. (low confidence) (verified as of 2025-05-15) — [source](https://intercom-help.mongodb.com/en/articles/11100710-mongodb-atlas-billing-changes-due-to-aws-updates) - Third-party guidance suggests downgrading one tier when average CPU is below 20% and peak below 40%, and claims 30-60% savings from combined optimizations. These are unverified estimates, not MongoDB figures. (low confidence) (verified as of 2026-03-31) — [source](https://oneuptime.com/blog/post/2026-03-31-mongodb-optimize-atlas-costs/view) - MongoDB advises considering an extra shard at sustained 60-70% utilization of RAM, vCPU or storage on a sizable machine. Its Atlas example is an M60 with a 4 TB disk. It states vertical scaling becomes increasingly expensive and that horizontal scaling is more predictable and cost-effective at scale. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-start-with-sharding/) - If a customer sets a custom storage size, Atlas bills the full custom amount and does not deduct the tier's default storage. Example: a 10 GB M10 raised to 50 GB is billed for 50 GB, not for the extra 40 GB. (high confidence) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - Atlas storage auto-scaling is enabled by default. It raises disk when used space reaches 90% on any node and sizes the new disk to reach 70% used on AWS, Azure and GCP. It only scales up. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-storage/) - If an auto-scaled disk would exceed the current tier's maximum storage, Atlas raises the cluster tier even when tier scaling is disabled (docs example: M30 to M40 when 600 GB is needed). This also disables automatic tier scale-down, so storage growth can silently raise the compute line item. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-storage/) - Plan for roughly 20% more disk than compressed data size under WiredTiger, because buffer, journal and log files and a no-overwrite engine consume space. Size forecasts from disk used, not from logical data size. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/customize-storage/) - Atlas automatic scalar quantization (int8) cuts mongot RAM by 3.75x and automatic binary quantization (int1) by 24x. Vector values themselves shrink 4x and 32x. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - MongoDB's 96% figure for binary quantization with rescoring is processing-memory reduction in MongoDB's own tests, not total storage. The post names no dataset or model, gives no chart values and uses 50 queries. (low confidence) (verified as of 2025-04-29) — [source](https://mongodb.com/blog/post/binary-quantization-rescoring-96-less-memory-faster-search) ## Problems, failure modes and limitations - NVMe clusters auto-scale to the next higher tier when 90% of storage is full, because storage cannot grow independently. This makes capacity planning a tier-cost decision. (high confidence) — [source](https://www.mongodb.com/docs/atlas/nvme-storage/) - NVMe operational constraints with cost impact: scaling needs a file-copy initial sync that degrades the source primary; backup cannot be disabled and hourly snapshots limited to every 12 hours; a hidden secondary with a provisioned volume supports backup; the cluster cannot be paused; no independent shard scaling. (high confidence) — [source](https://www.mongodb.com/docs/atlas/nvme-storage/) - Read-only and analytics nodes do not participate in elections, cannot become primary, and so provide no high availability. Analytics nodes are available on dedicated (M10+) clusters only, not Free or Flex. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/) - Atlas requires the same number of electable, read-only and analytics nodes, the same storage capacity and the same NVMe tier on every shard (Global clusters may vary node counts per zone). Storage cannot be sized per shard, so a hot shard forces extra storage cost on all shards. (high confidence) (verified as of 2026-10-18) — [source](https://mongodb.com/docs/atlas/cluster-sharding/) - Poor shard-key choice and queries lacking the shard key are the main hidden costs: scatter-gather queries are broadcast to all shards and run long, and resharding is slow and resource intensive. (medium confidence) — [source](https://www.mongodb.com/docs/manual/sharding/) - If a tier scale-down target cannot support the current disk capacity or IOPS, Atlas does not scale the cluster down. An oversized disk therefore blocks compute savings. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-storage/) - Atlas cannot shrink storage in place on AWS, Azure or GCP. It provisions new volumes and resyncs from the old ones, which causes downtime on each node during the sync, and sync time grows with data size. Over-provisioning is therefore sticky cost, so do not size up speculatively. (high confidence) — [source](https://www.mongodb.com/docs/atlas/customize-storage/) ## Comparisons and alternatives - Three node classes trade RAM:vCPU and storage: low-CPU 8:1 (vector search, low data volume), high-CPU 2:1 (lexical search, heavy indexing/query), storage-optimized 8:1 with 375-6000 GB (large indexes, moderate load). MongoDB claims storage-optimized nodes cut Search Node storage cost up to 50% and are about 40% cheaper than high-CPU when RAM-anchored. List prices agree in direction: AWS S40-S $0.25/hr vs high-CPU S40 $0.48/hr, both 16 GB RAM. Choose storage-optimized when storage is the constraint and CPU is moderate. (medium confidence) (verified as of 2026-09-29) — [source](https://mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Low-CPU tiers keep the same RAM and storage range as the General tier of the same size but halve vCPUs: on AWS Gen2 M40 has 4 vCPU and M40 Low-CPU (R40) has 2 vCPU, both 16 GiB RAM and 10 GB-1 TB storage; M50 has 8 vCPU vs R50 4 vCPU at 32 GiB. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws/) - NVMe storage and RAM are fixed per tier, not user-selectable: AWS M40_NVME 380 GB, M50_NVME 760 GB (vs General 80/160 GB defaults, scalable to 1/4 TB). NVMe M40 shows 15.25 GB RAM; the instance has 2 vCPU (i8g.large), same as Low-CPU. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws/) - MongoDB positions a smaller analytics tier as a cost saving versus scaling the whole cluster tier for BI workloads. The announcement gives no price figures. (medium confidence) — [source](https://www.mongodb.com/company/blog/product-release-announcements/introducing-ability-independently-scale-atlas-analytics-node-tiers) - Independent vendors corroborate the shape of the trade-off. Azure AI Search says int8 gives a 4x and binary up to 28x vector index size reduction, and that binary works best above 1024 dimensions with zero-centred embeddings. Elastic calls naive binary quantization exceptionally lossy and needing 10x-100x reranking candidates. Elastic's improved BBQ reaches over 90% recall at 3x oversampling on 1024-dimension Cohere vectors. (high confidence) (verified as of 2026-07-02) — [source](https://learn.microsoft.com/en-my/Azure/search/vector-search-how-to-quantization) ## Facts and statements - Dedicated Search Nodes require an M10+ cluster and a minimum of 2 nodes per cluster, up to 32 per region per shard. On sharded clusters Atlas deploys the node set per shard (2 nodes x 3 shards = 6 nodes), so the node floor multiplies with shard count. (high confidence) — [source](https://mongodb.com/docs/atlas/atlas-search/about/deployment-options) - Search Nodes bill hourly per node, and a partial hour counts as a full hour. Adding or removing a node bills the new configuration immediately. Changing tier bills both old and new instances for the first hour. A replacement of an unhealthy node is free. Network charges cover traffic between Search Nodes and database nodes and appear at cluster level, not as a Search Node line item. (high confidence) — [source](https://mongodb.com/docs/atlas/billing/search-node) - MongoDB announced an S10 Dedicated Search Node tier on 2026-07-23 on AWS, GCP and Azure as a lower-cost entry below S20, aimed at M10/M20/M30 clusters. The announcement gives no price or spec, and the deployment-options page still states S20 as the production minimum. (medium confidence) (verified as of 2026-07-23) — [source](https://www.mongodb.com/products/updates/introducing-the-s10-dedicated-search-node-tier/) - Search Node cost is additive to the base cluster: node count x tier rate, plus search-to-database transfer billed under cluster network charges. Pricing-page cluster rates do not include Search Nodes, so model them as a separate line (the sibling multi-region transfer concept covers network cost). (medium confidence) — [source](https://mongodb.com/docs/atlas/billing/search-node) - In the Atlas Administration API, an R prefix in the tier name (R40, R50) selects the Low-CPU variant via replicationSpecs[n].regionConfigs[m].electableSpecs.instanceSize. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws/) - Atlas docs say Low-CPU may also carry fewer max connections depending on tier; the AWS reference page does not list connection limits, so check the connection-limits page before downsizing. (low confidence) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws/) - NVMe tiers use locally attached ephemeral NVMe SSD, are available only on AWS (Gen2: M40, M50, M60, M80, M200, M400) and Azure (M60, M80, M200, M300, M400, M600), not on Google Cloud, not in multi-cloud clusters, and not on Atlas Infinite. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/nvme-storage/) - Low-CPU tiers are supported on Atlas Core from M40 and on Atlas Infinite (public preview) M40-M60; General from M10. M10/M20 use burstable infrastructure that can throttle CPU. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-tier/) - Atlas data transfer cost depends on the cloud provider hosting the cluster. The docs rank paths from lowest to highest cost, and name queries from on-premises into Atlas, traffic across cloud providers, and traffic between continents on one provider as the highest-cost paths. (medium confidence) — [source](https://mongodb.com/docs/atlas/billing/data-transfer-costs) - MongoDB's AWS pricing page lists Atlas data transfer at $0.01/GB same region, $0.02/GB cross-region and $0.09/GB internet. M0, M2 and M5 are exempt. The page gives no date for these rates, while its instance pricing says January 2022. (medium confidence) (verified as of 2026-10-18) — [source](https://mongodb.com/mongodb-on-aws/pricing) - Multi-region clusters might have higher data transfer costs, depending on the number and location of additional regions and the number of clusters per region. The docs give no formula or worked example. (high confidence) — [source](https://mongodb.com/docs/atlas/billing/data-transfer-costs) - Raw AWS billing: cross-AZ transfer is billed $0.01/GB in each direction, so about $0.02/GB effective. A 2019 test of US inter-region transfer (Virginia to Oregon) billed only the sender, about $0.02/GB. That test found inter-region the same per-GB cost as cross-AZ, not double as the pricing table implied. (low confidence) (verified as of 2019-10-21) — [source](https://www.lastweekinaws.com/blog/aws-cross-az-data-transfer-costs-more-than-aws-says) - Documented mitigations: use the 'nearest' read preference for cross-region reads, send cross-region writes from the Highest Priority Region, keep clients in the cluster's region and provider, project only needed fields, and enable driver network compression. Atlas already compresses intra-cluster traffic. (medium confidence) — [source](https://mongodb.com/docs/atlas/billing/data-transfer-costs) - Log export to external services routes through the Atlas control plane in AWS us-east-1 regardless of cluster region or provider. A cluster outside us-east-1 pays cross-region or inter-cloud charges on top of internet egress. (low confidence) — [source](https://mongodb.com/docs/atlas/billing/data-transfer-costs) - Atlas does not charge for incoming data transfer to a cluster, and the Atlas Live Migration Service is free. (low confidence) — [source](https://mongodb.com/docs/atlas/billing/data-transfer-costs) - Atlas requires the total number of electable nodes across all providers and regions in a cluster to be 3, 5, or 7. Electable nodes provide high availability and can become primary. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/) - Atlas deploys all data-bearing servers in a cluster at the selected cluster tier, and the per-hour charge covers that tier's default RAM and storage. Each added data-bearing node is therefore a full node at the same hourly tier cost, except analytics nodes with a separate tier. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs/) - Customizing storage is billed at the full custom amount, not the increment over the tier default. Every data-bearing node carries that storage, so storage customization multiplies with node count. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs/) - Atlas enforces a three-node minimum for dedicated replica sets, so a test environment pays for two idle secondaries. A MongoDB staff reply (Sept 2024) defended the minimum for availability; the requester rejected it. (low confidence) (verified as of 2024-09-11) — [source](https://www.mongodb.com/community/forums/t/feature-request-possibility-to-reduce-number-of-nodes-in-replicaset-for-stg-test-environments/296384) - Multi-region clusters can incur higher data transfer costs depending on the number and location of added regions. Atlas compresses intra-cluster communication. The data transfer page does not say whether same-region or cross-AZ replication traffic is billed. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/data-transfer-costs) - Changing an electable node to read-only is done by adding a read-only node and removing an electable node in one operation. Atlas does not guarantee that an analytics node keeps its hostname after a topology change, so connection strings should use replica set tags, not hostnames. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/) - Atlas charges instance and storage cost for each data-bearing node. For a sharded cluster the node count is replication factor x number of shards (3 shards at RF 3 = 9 nodes). (high confidence) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - The Atlas billing page does not mention a mongos router charge, tier minimums or per-tier hourly prices. Cost modelling must take the rates from the instance-size pricing section or the pricing calculator. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - Every shard must be a replica set, so the minimum footprint of one shard is a multi-node replica set, and the cluster adds config server nodes on top. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding/) - Independent shard scaling lets each shard use its own compute tier and, on AWS and Azure, its own IOPS. It is the default for clusters created on or after 2024-12-09; older clusters scale all shards together. It is controlled through the Admin API, CLI or Terraform, not the UI, and after using it the Cluster Builder UI can no longer manage the cluster. The auto-scaler permits at most a 2-tier gap between the highest and lowest shard. (medium confidence) (verified as of 2026-10-18) — [source](https://mongodb.com/docs/atlas/cluster-sharding/) - MongoDB 8.0 config shards let a sharded cluster run without dedicated config servers. In Atlas, sharded clusters with up to 3 shards on 8.0 use config shards by default, which removes the separate three-node config server charge for small clusters. (low confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/manual/core/sharding-start-with-sharding/) - Sharding on Atlas requires an M30 or larger cluster. (medium confidence) (verified as of 2026-10-18) — [source](https://mongodb.com/docs/atlas/cluster-sharding/) - Atlas Core storage speed is tied to capacity on Gen1, Azure and GCP: raising capacity raises max IOPS at no extra charge, and extra IOPS beyond that costs more. On AWS Gen1, choosing a custom speed (Fast/Fastest) switches the volume from general-purpose SSD to provisioned-IOPS SSD and adds cost. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - Gen2 Dedicated clusters (M30+, AWS/GCP) charge for storage including a baseline IOPS tied to disk size, and bill Extended Standard IOPS separately above that baseline. After switching Gen1 to Gen2, Atlas recommends re-tuning capacity and IOPS independently to cut cost. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - AWS EBS allows at most four modifications per volume in a rolling 24 hours and a volume resize can take hours. Atlas delays further capacity or IOPS changes until AWS permits another, so a fast-growing cluster can hit the cap during bulk loads. (high confidence) — [source](https://www.mongodb.com/docs/atlas/customize-storage/) - Replica sets are limited to 4 TB per node. Beyond that, Atlas recommends sharding for long-term growth; extended storage is a temporary fix that slows initial syncs and can reduce availability. (medium confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/customize-storage/) - Paused clusters still incur storage charges for the default storage; no other service or transfer charges apply. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs) - Ingesting pre-quantized BSON BinData vectors (float32, int8, int1 subtypes) needs about three times less disk space than a standard float32 array. Requirements: MongoDB 6.0.11/7.0.2 or later and a supported driver (Node.js 6.11+, PyMongo 4.10+, Java 5.3.1+). int1 supports euclidean similarity only and needs dimensions in multiples of 8. (low confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - MongoDB recommends binary quantization with rescoring for most embedding models, and scalar quantization for lower-dimension models that are not quantization-aware trained. Scalar gave the highest average recall in MongoDB's own chart. Binary assumes a zero midpoint, so it suits normalised embeddings. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - Binary quantization is risky for low-dimension embeddings. Elastic's own post notes a smaller speed advantage on 384-dimension-class E5-small, and Azure advises testing quality or using scalar below 1024 dimensions. Validate recall on your own data before downsizing a tier. (medium confidence) — [source](https://learn.microsoft.com/en-my/Azure/search/vector-search-how-to-quantization) - Azure lets binary-quantized indexes discard original vectors (discardOriginals) and rescore with the binary dot product, saving disk. Atlas documents no equivalent: binary rescoring there reads full-fidelity float vectors from disk. (low confidence) (verified as of 2026-07-02) — [source](https://learn.microsoft.com/en-my/Azure/search/vector-search-how-to-quantization)