A database running on one server can become unavailable when that server fails. A MongoDB replica set uses cooperating database processes: a primary accepts writes and other members maintain copies, with an election when a new primary is needed. This entry describes a historical chart that deployed that arrangement. It is not a different database product, and the topology still needs deliberate choices about voting members, acknowledged writes, client reconnection and backups.
Current guidance
The historical stable/mongodb-replicaset chart is deprecated. Its name describes a MongoDB replica-set deployment, not a separate database product. Current MongoDB documentation defines a replica set as cooperating mongod processes with a primary and secondaries, with elections when the primary becomes unavailable.
Design the voting topology and failure domains deliberately. An arbiter votes but stores no data, so counting it as another recoverable copy would overstate redundancy. Replication lag, write concern and client connection settings affect the behavior observed during failover; merely running three pods does not settle those choices.
Before replacing the old package, preserve replica-set identity, member addresses, credentials and persistent volumes. Rehearse the chosen database upgrade or migration on a restored copy, then test election, client reconnect and a member resynchronization. Do not equate replication with backup: accidental deletions can propagate to every member. The chart retirement does not retire MongoDB, and a current operator or chart should be assessed separately rather than treated as a values-compatible substitute.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
MongoDB is an open-source document database and leading NoSQL database. MongoDB is written in C++. This tutorial will give you the great understanding of MongoDB concepts needed to create and deploy a highly scalable and performance-oriented database.
Overview
MongoDB is a cross-platform, document-oriented database that provides, high performance, high availability, and easy scalability. MongoDB works on the concept of collection and document.
Database
The database is a physical container for collections. Each database gets its own set of files on the file system. A single MongoDB server typically has multiple databases.
Collection
A collection is a group of MongoDB documents. It is the equivalent of an RDBMS table. A collection exists within a single database. Collections do not enforce a schema. Documents within a collection can have different fields. Typically, all documents in a collection are of similar or related purpose.
Document
A document is a set of key-value pairs. Documents have the dynamic schema. Dynamic schema means that documents in the same collection do not need to have the same set of fields or structure, and common fields in a collection’s documents may hold different types of data.
Key Features
High Performance
MongoDB provides high-performance data persistence. In particular,
- Support for embedded data models reduces I/O activity on the database system.
- Indexes support faster queries and can include keys from embedded documents and arrays.
Rich Query Language
MongoDB supports a rich query language to support read and write operations (CRUD) as well as:
- Data Aggregation
- Text Search and Geospatial Queries.
High Availability
MongoDB’s replication facility, called a replica set, provides:
- automatic failover and
- data redundancy.
A replica set is a group of MongoDB servers that maintain the same data set, providing redundancy and increasing data availability.
Horizontal Scalability
MongoDB provides horizontal scalability as part of its core functionality:
- Sharding distributes data across a cluster of machines.
- Starting in 3.4, MongoDB supports creating zones of data based on the shard key. In a balanced cluster, MongoDB directs reads and writes covered by a zone only to those shards inside the zone. See the Zones manual page for more information.
- Support for Multiple Storage Engines
- MongoDB supports multiple storage engines:
- WiredTiger Storage Engine (including support for Encryption at Rest)
- In-Memory Storage Engine
- MMAPv1 Storage Engine (Deprecated in MongoDB 4.0)
In addition, MongoDB provides pluggable storage engine API that allows third parties to develop storage engines for MongoDB.
MongoDB – Advantages
Any relational database has a typical schema design that shows the number of tables and the relationship between these tables. While in MongoDB, there is no concept of relationship.
Advantages of MongoDB over RDBMS
- Schema-less − MongoDB is a document database in which one collection holds different documents. The number of fields, content, and size of the document can differ from one document to another.
- Structure of a single object is clear.
- No complex joins.
- Deep query-ability. MongoDB supports dynamic queries on documents using a document-based query language that’s nearly as powerful as SQL.
- Tuning.
- Ease of scale-out − MongoDB is easy to scale.
- Conversion/mapping of application objects to database objects not needed.
- Uses internal memory for storing the (windowed) working set, enabling faster access to data.
Why Use MongoDB?
- Document Oriented Storage − Data is stored in the form of JSON style documents.
- Index on any attribute
- Replication and high availability
- Auto-sharding
- Rich queries
- Fast in-place updates
- Professional support by MongoDB
Where to Use MongoDB?
- Big Data
- Content Management and Delivery
- Mobile and Social Infrastructure
- User Data Management
- Data Hub
Sources & further reading
Spotted something that needs another look?
Help improve this page →