A short history of MongoDB

Relational databases dominated enterprise data for decades, yet many teams building fast-moving web products hit the same wall: schemas that changed weekly, data that looked like JSON in the application, and sharding stories that required specialists. MongoDB arrived as one answer in the document corner of the NoSQL space—not because SQL failed everywhere, but because a flexible document model matched how Node.js and other application stacks already thought about data.

The NoSQL label and why it appeared

NoSQL never meant “no SQL forever.” It meant not only SQL: systems that traded some relational guarantees for horizontal scale, flexible schemas, or simpler deployment on commodity hardware. The late 2000s saw explosive growth in read-heavy web traffic, agile product iteration, and semi-structured logs and profiles that did not map cleanly to fixed tables.

Four broad families still help you place products:

Family	Idea	Examples
Key-value	Opaque blob keyed by string	Redis, DynamoDB (item mode)
Document	JSON-like documents with query on fields	MongoDB, CouchDB
Wide-column	Sparse rows grouped in column families	Cassandra, HBase
Graph	Nodes and edges as first-class	Neo4j

MongoDB is a document database: each record is a BSON document (binary JSON), grouped in collections, with indexes and a rich query language on nested fields.

Distributed systems textbooks often contrast ACID transactions (strong consistency on one node or a coordinated cluster) with BASE (basically available, soft state, eventual consistency). Early MongoDB marketing emphasized availability and partition tolerance; later releases added multi-document ACID transactions (4.0+) so teams could choose consistency where the schema required it without giving up the document model.

From 10gen to MongoDB Inc.

Dwight Merriman, Eliot Horowitz, and Kevin Ryan founded 10gen in 2007 to build a platform-as-a-service stack. The database they wrote for that stack became the product. MongoDB 1.0 shipped in 2009 as open source. The company renamed to MongoDB Inc. in 2013 as the database outgrew the original PaaS vision.

The default storage engine was long MMAPv1. MongoDB 3.0 (2015) made WiredTiger the default: document-level locking, compression, and better write concurrency. That engine still underpins modern releases and supports encryption at rest on supported platforms.

Atlas, drivers, and the application stack

MongoDB Atlas (2016) moved provisioning, backups, and monitoring into a managed cloud service. Application code typically talks to Atlas or self-hosted deployments through the official Node.js driver (mongodb on npm), which maps CRUD, aggregation, and sessions to wire protocol messages. Higher-level ODMs such as Mongoose sit on top of that driver; this series uses the driver first and dedicates a chapter to Mongoose.

Features that changed expectations

Several releases shifted what teams assumed a document database could do:

Multi-document ACID transactions (4.0): startSession, withTransaction, and snapshot reads for coordinated updates across collections.
Server Side Public License (SSPL) (2018): replaced AGPL for server code; relevant when you redistribute MongoDB as a service, less so for normal application development.
Queryable Encryption and improved security tooling: field-level encryption paths for regulated data without abandoning rich queries on other fields.
MongoDB 8.0 (2024+): continued performance work on the WiredTiger path, time-series improvements, and tighter integration with search and vector workloads on Atlas.

MongoDB acquired Voyage AI (2024) to deepen embedding and reranking in Atlas, so semantic search and RAG pipelines can stay closer to the data layer.

Diagram 1

timeline
  title MongoDB milestones
  2007 : 10gen founded
  2009 : MongoDB 1.0 open source
  2015 : WiredTiger default (3.0)
  2016 : MongoDB Atlas
  2018 : Multi-document transactions (4.0)
  2018 : SSPL license
  2024 : MongoDB 8.0 major
  2024 : Voyage AI acquisition

MongoDB in the document-database niche

Compared to relational databases, MongoDB optimizes for nested documents, optional fields, and horizontal sharding when a single replica set is not enough. Compared to pure key-value stores, it offers secondary indexes, aggregation pipelines, and (on Atlas) full-text and vector search. The tradeoff is discipline in schema design: unlimited flexibility can hide performance traps until production traffic arrives.

That design tension—speed of iteration versus query patterns—is why the rest of this series covers modeling, indexes, and pagination before search and embeddings.

Next: Installing and connecting to MongoDB.