Document Databases
Concept
The most popular type of NoSQL database is the Document Database. The absolute market leader in this category is MongoDB.
In a relational database, data is shattered across multiple tables. To load a blog post, you have to query the posts table, JOIN the authors table, and JOIN the comments table.
In a Document Database, the entire blog post (the author, the text, and the array of comments) is stored together as a single, hierarchical JSON document (technically BSON in MongoDB).
The Core Advantages
1. Developer Ergonomics
If your Node.js backend uses Javascript objects, and your React frontend uses Javascript objects, storing the data as a JSON document means there is zero translation required. You do not need a massive ORM (Object-Relational Mapper) to convert SQL rows into Javascript objects. You just insert the Javascript object directly into the database.
2. High-Speed Reads
Because all the data for a specific entity is grouped together in one physical document on the hard drive, loading a blog post requires exactly one disk read. There are no expensive CPU JOIN operations required.
3. Schemaless Iteration
If you are rapidly prototyping a startup and adding new features every day, a strict SQL schema is annoying. With a Document Database, you can just start injecting new properties ({"has_premium_badge": true}) into the documents without running any database migrations.
The Massive Drawback: Duplication
Because Document Databases actively discourage JOIN operations, you are forced to Denormalize your data.
If “Alice” writes 50 blog posts, and her name is embedded directly inside the 50 JSON documents, what happens when she changes her name to “Alicia”?
In a SQL database, you update her name in exactly one row in the users table.
In MongoDB, you must manually write a script to search the entire database and update the string inside all 50 separate JSON documents. If your script crashes halfway through, your database is permanently corrupted with inconsistent data.
Interview Questions
Q: A developer is building a Financial App to transfer money between accounts. They choose MongoDB. In older versions of MongoDB (pre-4.0), what catastrophic risk were they taking?
A: Older versions of MongoDB did not support Multi-Document Transactions.
They only guaranteed atomicity at the single document level. If the developer deducted 50 to Account B (Document 2), the $50 vanished into thin air. A SQL database would have rolled back the entire transaction. (Note: MongoDB 4.0+ added multi-document ACID transactions, effectively solving this historic criticism).
Q: If Document Databases are so flexible, why does PostgreSQL’s JSONB feature exist?
A: PostgreSQL introduced JSONB to give developers the exact same developer ergonomics and schemaless flexibility of MongoDB, without sacrificing the strict, relational safety of a SQL database. Today, many architects argue that there is very little reason to use MongoDB for a new project, as PostgreSQL JSONB with a GIN index can perform document storage just as effectively, while still allowing you to enforce Foreign Keys and standard JOINs on the rest of your core relational data.