Should I use single node replica set for production?

Hi folks,

we are running MongoDB on premise with docker compose. In the development environment we run a single node replica set because we use multi document transactions. In production we run usually three nodes in the replica set. A customer doesn’t care about hot backup and has only one machine. Now, the MongoDB manual says: “Use standalone instances for testing and development, but always use replica sets in production.”

Long story short: Is it recommended to run a single node replica set in production environment (apart of the obvious fact that if this node fails everything fails - it’s a single PC system, so, if this PC fails, everything fails)?

Thanks, cheers, Daniel

It is not all recommended for prod
You should have minimum 3 node cluster with each node in a different data center for maximum availability/fault tolerance

1 Like

Hi @Daniel_Camarena ,

As per @Ramachandra_Tummala (and the MongoDB server manual), the strong recommendation is to deploy a minimum of a three node replica set for production use cases as this provides:

  • data redundancy
  • high availability and failover
  • administrative convenience for upgrades without downtime

If all replica set members are on the same physical host you will have a single point of failure if the host server goes down, but can still realise some of the benefits of multiple copies of data and multiple redundant mongod processes. A more ideal deployment would have replica set members on separate physical hosts, as these processes will also be competing for the same system resources on a shared host.

However, If those benefits are not important for your customer’s use case you can of course choose to deploy a more minimal configuration with operational risks.

I would make sure you have an appropriate (and tested!) plan for backup and recovery for any production deployments. Single points of failure will usually adversely affect SLAs and Recovery Time Objectives if a deployment needs to be completely rebuilt after catastrophic failure.


1 Like

Dear @Ramachandra_Tummala,

thank you for your suggestions. As I mentioned:

  • there is only one machine
  • of course it is more secure to have 3 machines, but we don’t have them
  • it is on premise, so, no data centers - just one host
    To make it more clear, the only web services accessing the data runs on the same host. So, no need to be available if this PC fails. Backups are made for cold backup / disaster recovery.

Thank you for your statements, regards, Daniel

Dear @Stennie,

thank you for the explication. But exactly there is my doubt: The MongoDB doesn’t state clearly that I should use 3 nodes for production. It states that I should use a replica set for production, which could be perfectly a single node replica set.

Data redundancy, high availability, failover and administrative convenience for upgrades without downtime are strong reasons for having three nodes. I have only one.

As the web service which is accessing the data is running on the same host, it doesn’t matter if the DB isn’t available anymore when the host fails.

Your point regarding system resources is exactly the point I’m aiming to: Why should I have 3 nodes competing for the same resources on the same physical machine, if one node is doing the same job perfectly?

Your point regarding backup is much more important in a single node replica set like this. There are backups made every x hours and copied to other machine for cold backup / disaster recovery.

Thank you, regards, Daniel

Hi @Daniel_Camarena,

You should read “replica set” as “minimum three member replica set” unless otherwise specified. The MongoDB manual does not encourage creating single member replica sets and always describes these as a group of mongod processes. The design intent of replica set deployments is to achieve all of the benefits I mentioned.

Per Replica Set Members:

The minimum recommended configuration for a replica set is a three member replica set with three data-bearing members: one primary and two secondary members.

There are other suboptimal replica set configurations like adding an arbiter (see Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie for some caveats) or having less than three members.

A single node replica set does not provide the same benefits as three members, but you can choose this deployment if the caveats are acceptable for your use case.

The difference is a recommended configuration for general production use cases versus a possible configuration for your specific requirements. It sounds like you are fine with a single node replica set.


Dear @Stennie,

thank you for your reply. It gives a good impression of where to focus on.

Yes, I am - if not, more than fine because with a single node replica set I gain a couple of advantages - not only disadvantages. If a single node replica set does the job in the same way than a 3 node replica set does, despite the obvious disadvantages of not having 3 nodes, I’m fine with that.

Just to sum up the pros and cons to use a single node replica set:

The last answer of @Stennie gives a complete impression. Read it!

Thank you, regards, Daniel

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.