Mongo DB - difference between standalone & 1-node replica set

Question

I needed to use Mongo DB transactions, and recently I understood that transactions don\'t work for Mongo standalone mode, but only for replica sets (Mongo DB with C# - docum

Answer 1

Is there any problem/disadvantage with running Mongo as a 1-node replica set, assuming I don't really need the replication, load balancing or any other scalable functionality?

You don't have high availability afforded by a proper replica set. Thus it's not recommended for a production deployment. This is fine for development though.

Note that a replica set's function is primarily about high availability instead of scaling.

What are the functionality and performance differences, if any, between running as standalone vs. running as a 1-node replica set?

A single-node replica set would have the oplog. This means that you'll use more disk space to store the oplog, and also any insert/update operation would be written to the oplog as well (write amplification).

So why is standalone mode not recommended? Is it not stable enough, or other reasons?

MongoDB in production was designed with a replica set deployment in mind, for:

• High availability in the face of node failures
• Rolling maintenance/upgrades with no downtime
• Possibility to scale-out reads
• Possibility to have a replica of data in a special-purpose node that is not part of the high availability nodes

In short, MongoDB was designed to be a fault-tolerant distributed database (scales horizontally) instead of the typical SQL monolithic database (scales vertically). The idea is, if you lose one node of your replica set, the others will immediately take over. Most of the time your application don't even know there's a failure in the database side. In contrast, a failure in a monolithic database server would immediately disrupt your application.