Replica Set Node Topology Cost

Parent: Atlas Cluster Topology and Tier Economics · Published reference · snapshot 2026-10-19 · skill mongodb-operations-expert/references/atlas-cluster-topology-and-tier-economics.md · viability 4.25 / 5 (research)

↓ Facts as markdown all context files

An Atlas replica set's cost scales with the number and tier of its data-bearing nodes: electable nodes must total 3, 5 or 7, read-only and analytics nodes add capacity without voting, and each data-bearing node is billed at the cluster tier's hourly rate plus its storage. Analytics nodes can use a different tier priced prorated per node, while arbiters are documented only for self-managed sets and the sources disagree on whether the three-node minimum is justified for test environments. Drawn from 9 source pages (MongoDB Atlas docs, manual and blog, forum threads, IBM Community and oneuptime blogs) across definitions, parameters, mechanism, problems and how-to.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

[1](1, 2) On Atlas Core clusters, data-bearing servers are the machines that run the nodes holding your application data. In a sharded cluster, each shard is a replica set whose members are the data-bearing servers. Sharded clusters may also use config servers, which are billed separately from the data-bearing servers. [source]
An arbiter has exactly 1 election vote. By default an arbiter has priority 0. [source]
MongoDB Atlas pricing is consumption based, i.e. every cluster tier has an hourly price attached. In addition to consumption charges displayed in MongoDB Atlas Cluster Configuration UI, data transfer, backup and support charges are added on top of hourly price. [source]
Use read-only nodes to optimize local reads in the nodes' respective service areas. [source]
We’re excited to announce analytics node tiers for MongoDB Atlas. Analytics node tiers provide greater control and flexibility by allowing you to customize the exact infrastructure you need for your analytics workloads. [source]

Structure and components

On Atlas Infinite clusters, data-bearing servers don't apply. Atlas stores and manages your data in a storage layer that is separate from the compute layer. The electable, read-only, and analytics nodes are compute nodes that access data in the storage layer. To learn more, see MongoDB Atlas Infinite: Architecture. [source]
A standard replica set contains a primary node for reads and writes and two secondary nodes that are read only. Analytics nodes provide an additional read-only node that is dedicated to analytical reads. [source]
Sharded clusters include additional nodes. The electable nodes on the dedicated Config Server Replica Set (CSRS) count towards the total number of allowable nodes. Each sharded cluster has an additional electable node per region as part of the dedicated CSRS. To learn more, see Replica Set Config Servers. [source]

How it works

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. [source]
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. [source]
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. [source]
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. [source]
A cluster tier selected on the Analytics Tier tab is priced the same as a cluster tier selected on the Base Tier tab. However, when an Analytics Tier is higher or lower than the Base Tier, the price adjusts accordingly on a prorated per-node basis. The pricing appears in the Atlas UI when you create or edit a cluster. To learn more, see, Manage Billing. [source]
The write concern "majority" can cause performance issues if a secondary is unavailable or lagging. For advice on how to mitigate these issues, see Mitigate Performance Issues in Self-Managed PSA Replica Sets. [source]
Teams with inconsistent needs may want to decrease their analytics node tier below that of their operational nodes. The ability to set a lower tier gives you flexibility and cost savings when you have fewer users or analytics are not your top priority. [source]
Atlas provides different cluster tiers. Each cluster tier has a default RAM capacity, storage capacity, and maximum storage speed. The cluster's per-hour charge includes these default values. Atlas uses the selected cluster when deploying all the data-bearing [1] servers in your cluster. [source]
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. [source] — Invoice line per forum thread; docs silent
Teams with large user bases using their BI dashboards may want to increase their analytics node tiers above that of their operational nodes. Choosing a higher tier can be useful when you have many users or require more memory to serve analytics needs. Scaling up the entire cluster tier would be costly, but scaling up just your analytics node tiers helps optimize the cost. [source]
Having a large number of regions or having nodes spread across long distances may lead to long election times or replication lag. [source]
When you migrate electable nodes from one region to another, Atlas immediately provisions new nodes and deprovisions old ones. Atlas does not wait for MongoDB Search indexes to finish building in the new region before deprovisioning old nodes, so you might experience MongoDB Search downtime during the creation of new indexes. [source]

Parameters and configuration

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. [source]
The total number of electable nodes across all providers and regions in the cluster must equal 3, 5, or 7. [source]
Atlas limits the total number of nodes in other regions in one project to a total of 100, not including: - Google Cloud regions communicating with each other - Free clusters - Flex clusters [source]
The number of availability zones, zones, or fault domains in a region has no effect on the number of MongoDB nodes Atlas can deploy. MongoDB Atlas clusters are always made of replica sets with a minimum of three MongoDB nodes. [source]

How-to and procedures

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. [source]
To improve the redundancy and availability of a cluster, increase the number of electable nodes in that region. Every Atlas cluster has a Highest Priority region. If your cluster spans multiple regions, you can select which cloud provider region should be the Highest Priority. [source]
In some circumstances (such as when you have a primary and a secondary, but cost constraints prohibit adding another secondary), you may choose to add an arbiter to your replica set. An arbiter participates in elections for primary but an arbiter does not have a copy of the data set and cannot become a primary. [source]
Use analytics nodes to isolate queries which you do not wish to contend with your operational workload. Analytics nodes help handle data analysis operations, such as reporting queries from BI Connector for Atlas. To direct queries to analytics nodes, use pre-defined replica set tags. [source]
Use a single arbiter to avoid problems with data consistency. Multiple arbiters prevent the reliable use of the majority write concern. [source]
To add these nodes to an Atlas Infinite cluster, specify the number of Nodes for each node type. Atlas deploys the nodes in the same region as the Atlas Infinite cluster, so you don't select a cloud provider or region for them. To learn which regions Atlas Infinite clusters support, see the Atlas Infinite Support column in the Amazon Web Services (AWS) regions table. [source]
To avoid this scenario, use at most a single arbiter. [source]

Measurements and reference values

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. [source] — Unverified third-party estimate

Problems, failure modes and limitations

To ensure that a write will persist after the failure of a primary node, the majority write concern requires a majority of nodes to acknowledge a write operation. Arbiters do not store any data, but they do contribute to the number of nodes in a replica set. When a replica set has multiple arbiters it is less likely that a majority of data bearing nodes will be available after a node failure. [source]
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. [source]
Read-only nodes don't provide high availability because they don't participate in elections. They can't become the primary for their cluster. To direct queries to read-only nodes, use pre-defined replica set tags. [source]
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. [source] — Forum thread, Sept 2024
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. [source]
Analytics nodes don't provide high availability because they don't participate in elections. They can't become the primary for their cluster. [source]
You cannot change a shard key using a transaction if the replica set has an arbiter. Arbiters cannot participate in the data operations required for multi-shard transactions. [source]
Starting in MongoDB 5.3, support for multiple arbiters in a replica set is disabled by default. If you attempt to add multiple arbiters to a replica set, the server returns an error: [source]
absolutely understand what you’re saying… the three-node minimum on Atlas might seem like overkill for a test environment, especially if you’re trying to keep costs low. But the thing is, that setup is what helps ensure high availability, even on the lower tiers. but it’s not just for production—having three nodes means if one goes down (like during maintenance or some unexpected issue), your environment stays available. [source] — MongoDB staff reply: needed for availability
If one wants high availability for the environment, one sets the desired number of instances accordingly, so I don’t buy the explanation about high availability. No environment (perhaps very few exceptions) needs the same availability for their test stg as they need for their production environment. [source] — Requester rejects availability argument
You can deploy analytics nodes for dedicated (M10 or higher) clusters only. You can't add analytics nodes on Free clusters or Flex clusters. [source]
Transactions whose write operations span multiple shards will error and abort if any transaction operation reads from or writes to a shard that contains an arbiter. [source]
MongoServerError: Multiple arbiters are not allowed unless all nodes [source]
Differently from competitors (e.g.: docdb), atlas forces a minimum of 3 nodes no matter what, and this doesn’t make any sense for a test environment, where we just want to be able to run staging applications on. As a consequence, this incurs 2 totally unutilized nodes we are paying for every month, increasing the costs considerably. Please consider enabling downsizing for test environments! [source]
One thing is instance type, another thing is number of instances. I don’t want to have a lower/slower tear. I want to have fewer instances running and under no use, spending resources unnecessarily… [source]

Comparisons and alternatives

Using a primary-secondary-arbiter (PSA) architecture for shards in a sharded cluster can cause a loss of availability if a data-bearing secondary is unavailable. A PSA cluster differs from a typical replica set: In a sharded cluster, shards perform w: majority write concern operations that cannot complete if the remaining cluster members required to confirm an operation have an arbiter. [source]
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. [source]

Facts and statements

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. [source]
Your workloads can vary greatly between analytics and operational nodes. To help manage this issue, for M10+ clusters, you can select a cluster tier appropriately sized for your analytics workload. You can select a cluster tier for your analytics nodes that's larger or smaller than the cluster tier selected for your electable and read-only nodes (operational nodes). This functionality helps to ensure that you get the performance required for your transactional and analytical queries without over or under provisioning your entire cluster for your analytical workload. [source]
For example, in the following replica set with 2 data-bearing members (the primary and a secondary), an arbiter allows the set to have an odd number of votes to break a tie: [source]
For a replica set, the number of data-bearing nodes equals the replication factor. [source]
If you select a cluster tier on the Analytics Tier tab significantly below the cluster tier selected on the Base Tier tab, replication lag might result. The analytics node might fall off the oplog altogether. [source]
If you have a cluster named foo123 containing an analytics node foo123-shard-00-03-a1b2c.mongodb.net:27017, Atlas does not guarantee that specific host name will continue to refer to an analytics node after a topology change, such as scaling a cluster to modify its number of nodes or regions. [source]
If you change the Highest Priority provider or region in an active multi-region cluster, Atlas selects a new primary node in the provider and region that you specify (assuming that the number of nodes in each provider and region remains the same and nothing else is modified). [source]
Source write queries from your Highest Priority Region whenever possible. For more information on region priorities, see Electable Nodes for High Availability. [source]
You can change an electable node to a read-only node by adding a read-only node and removing an electable node at the same time. To learn more, see Change Workload Purpose of Nodes. [source]
For a sharded cluster, the number of data-bearing nodes equals the replication factor multiplied by the number of shards. [source]
Do not run an arbiter on systems that also host the primary or the secondary members of the replica set. [source]
On Atlas Core clusters, if you select a General cluster tier on the Analytics Tier tab and a Low-CPU cluster tier on the Base Tier tab, disk auto-scaling isn't supported for the cluster. Disk auto-scaling also isn't supported if you select a General cluster tier on the Base Tier tab and a Low-CPU cluster tier on the Analytics Tier tab. [source]
On Atlas Core clusters, storage size must match between the Base Tier tab and Analytics Tier tab. You can set the storage size on the Base Tier tab. Atlas expands the storage of an Atlas Infinite cluster as your data grows, so you don't set a storage size. [source]
On Atlas Core clusters, if you want to select the Local NVME SSD class on the Base Tier tab, the Analytics Tier tab must have the same tier level selected. Atlas Infinite clusters don't support locally attached NVMe SSD storage in public preview. [source]
Until now, analytics nodes in MongoDB’s Atlas clusters have used the same cluster tier as all other nodes. However, operational and analytical workloads can vary greatly in terms of resource requirements. Analytics node tiers allow you to enhance the performance of your analytics workloads by choosing the best tier size for your needs. This means you can choose an analytics node tier larger or smaller than the operational nodes in your cluster. This added level of customization ensures you achieve the performance required for both transactional and analytical queries — without the need to over [source]
Atlas sets the node in the first row of the Electable nodes table as the Highest Priority region. Atlas prioritizes nodes in this region for primary eligibility. Other nodes rank in the order that they appear. For more information, see Member Priority. [source]
Atlas does not guarantee that host names remain consistent with respect to node types during topology changes. [source]
For Atlas Infinite clusters in public preview, specify the number of Nodes. Atlas deploys them in the same region as the Atlas Infinite cluster. For Atlas Core clusters, click Add a region to select a region, then specify the number of Nodes for that region. [source]
On Atlas Infinite clusters in public preview, Atlas deploys all nodes in one region on AWS. You can deploy read-only and analytics nodes to isolate workloads from your primary node. To learn more, see Workload Isolation on Atlas Infinite clusters. [source]
After you add your analytics nodes, you can select a cluster tier appropriately sized for your analytics workload. [source]
Atlas Infinite clusters don't support adding additional electable nodes. [source]
Atlas charges the cluster cost and data storage cost for each data-bearing node [1] in your cluster. [source]
If a secondary node falls behind the primary, and the cluster is reconfigured, votes from multiple arbiters can elect the node that had fallen behind. The new primary will not have the unreplicated writes even though the writes could have been majority committed by the old configuration. The result is data loss. [source]

Disagreements

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. [source] — Forum thread, Sept 2024
absolutely understand what you’re saying… the three-node minimum on Atlas might seem like overkill for a test environment, especially if you’re trying to keep costs low. But the thing is, that setup is what helps ensure high availability, even on the lower tiers. but it’s not just for production—having three nodes means if one goes down (like during maintenance or some unexpected issue), your environment stays available. [source] — MongoDB staff reply: needed for availability
If one wants high availability for the environment, one sets the desired number of instances accordingly, so I don’t buy the explanation about high availability. No environment (perhaps very few exceptions) needs the same availability for their test stg as they need for their production environment. [source] — Requester rejects availability argument

Related concepts

analytics node — is a part of Replica Set Node Topology Cost
arbiter — is a part of Replica Set Node Topology Cost
electable node — is a part of Replica Set Node Topology Cost
data-bearing node — is a part of Replica Set Node Topology Cost
base tier — is a part of Replica Set Node Topology Cost
election — is a measure of Replica Set Node Topology Cost
high availability — is a measure of Replica Set Node Topology Cost
read-only node — is a part of Replica Set Node Topology Cost
three-node minimum — is a problem of Replica Set Node Topology Cost
majority write concern — is a problem of Replica Set Node Topology Cost
Highest Priority region — is a part of Replica Set Node Topology Cost
replication lag — is a problem of Replica Set Node Topology Cost
data transfer — is a related of Replica Set Node Topology Cost
multi-region — is a related of Replica Set Node Topology Cost
replica set tags — is a related of Replica Set Node Topology Cost
hourly tier cost — is a measure of Replica Set Node Topology Cost
replication factor — is a measure of Replica Set Node Topology Cost
prorated per node — is a measure of Replica Set Node Topology Cost
cost optimization — is a hypernym of Replica Set Node Topology Cost
storage customization — is a measure of Replica Set Node Topology Cost

Children

Analytics node tier prorating (frontier)
Intra-cluster replication transfer billing (frontier, viability 2.80 / 5, below research gate)

Frontier under this node: Analytics node tier prorating, Intra-cluster replication transfer billing (2.80)

← the whole tree · 3D view· how to read this page