We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Database Types & Storage
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
In short
A document database is a NoSQL database that stores each record as a self-contained document, usually JSON or BSON, where fields and nested structures can vary from one document to the next. Instead of spreading related data across many tables joined by keys, it keeps everything for one entity in a single document you read and write in one operation.
In short
A document database is a NoSQL database that stores each record as a self-contained document, usually JSON or BSON, where fields and nested structures can vary from one document to the next. Instead of spreading related data across many tables joined by keys, it keeps everything for one entity in a single document you read and write in one operation.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Document Database across a run of lessons, not one page. These 4 alone are about 144 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
Databases that think in JSON, flexible schemas for modern applications.
Delta Lake, Apache Iceberg and Apache Hudi: what is actually in the metadata? I wrote the same 11,198,026 NYC taxi trips into all three, three commits each, and opened every metadata file. Delta kept 3 JSON commits, Iceberg 10 files in a four-level tree, Hudi a timeline and a metadata table. All three returned January's exact 3,475,226 rows when asked for the first version. After 120 small appends, an Iceberg planner opened 122 metadata files and a Delta reader 22; Hudi packed the rows into 1 file group instead of 120 files. Compaction fixed the count, and cleanup ended time travel.
Database model comparison, relational vs non-relational data stores.
How key-value databases work, how to design good keys, and how Redis, DynamoDB and etcd compare. Includes a diagram of a GET and SET operation.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Document Storespay once,
yours for life
A document is a set of key value pairs, where values can be strings, numbers, arrays, or other nested documents. A product record might hold its name, price, an array of tags, and an embedded object for shipping dimensions, all in one place. Documents that describe the same kind of thing are grouped into a collection, which is the rough equivalent of a table.
The defining feature is that there is no fixed schema enforced across a collection. One user document can have a phone field, the next can skip it and add a list of saved addresses instead. The database does not reject that. The structure lives in the document, not in a central table definition you have to migrate.
This maps closely to how objects look in application code. A JavaScript object or a Python dict serializes almost directly into a document, so you avoid the translation layer that relational databases need between rows and objects.
Each document gets a unique id, and the database builds a primary index on that id so single document lookups are fast. To make queries on other fields fast, you add secondary indexes on those fields, for example an index on email or on a nested field like address.city. Without an index, a query scans every document in the collection.
Storage is usually a binary form rather than raw text. MongoDB stores BSON, a binary JSON variant that adds types like dates and 64 bit integers and makes traversal faster. Documents are written and read as a whole unit, which is why a single document update is atomic by default even when it touches several nested fields.
Because everything for one entity sits together, the common read pattern is one lookup with no joins. The trade you make is duplication. If an author name is embedded inside a thousand book documents and the author renames, you update a thousand documents instead of one row in an authors table.
Reach for a document database when your data is naturally hierarchical, when each record varies in shape, or when the schema changes often and you do not want to run a migration every time. Catalogs, user profiles, content management, event logs, and configuration stores all fit well. It also suits rapid early development where the data model is still moving.
Avoid it when your data is highly relational and you run many cross entity queries. A banking system that constantly joins accounts, transactions, and customers is cleaner in a relational engine with real joins and strong multi row transactions. Document databases historically had weak multi document transactions, though MongoDB added multi document ACID transactions in version 4.0 in 2018.
The biggest practical risk is undisciplined schemas. Flexibility means nothing stops two parts of your code from spelling the same field differently or storing a price as a string in some documents and a number in others. Teams usually enforce a schema in the application layer or with tools like MongoDB schema validation to keep that under control.
Take an e commerce order. In a relational database you would split it across an orders table, an order_items table, a shipping_address table, and a customer table, then join four tables to render one order page. In a document database the entire order, including the line items array and the shipping address object, lives in a single order document.
Rendering the order page becomes one read by order id. Creating the order becomes one atomic write. If a later feature needs to store gift wrap notes per line item, you just add that field to new documents without touching the existing ones or running a migration.
The cost shows up in reporting. A question like total revenue per product across all orders has to scan and aggregate across many documents, where a relational database could answer it with a tight join and a GROUP BY. This is the core tension: document databases optimize for reading and writing whole entities, not for slicing data across entities.
MongoDB
The most widely used document database, storing data as BSON and powering catalogs, user data, and content systems at companies from eBay to Forbes.
Amazon DynamoDB
A managed key value and document store that backs Amazon retail and serves single digit millisecond reads at very large scale.
Couchbase and CouchDB
JSON document stores; CouchDB pioneered multi master replication, and Couchbase is used for low latency caching plus persistence at companies like LinkedIn.
Firebase Firestore
Google's serverless document database with real time sync, common in mobile and web apps that need offline support and live updates.
A relational database stores data in tables with a fixed schema and links records using foreign keys and joins. A document database stores each record as a self-contained JSON-like document with a flexible shape and usually embeds related data instead of joining. Relational wins on complex cross entity queries and strict consistency; document wins on flexible schemas and reading whole entities fast.
Yes. MongoDB is the most popular document database. It stores records as BSON documents, groups them into collections, and lets each document have a different structure with no enforced table schema.
No. JSON is a text format for representing structured data. A document database is a system that stores, indexes, and queries documents, which are often JSON or a binary variant like MongoDB's BSON. JSON is the shape of the data; the document database is the engine that manages it.
Single document writes have always been atomic. Multi document transactions came later: MongoDB added multi document ACID transactions in version 4.0 in 2018. They work but are heavier than relational transactions, so the usual design goal is to keep related data in one document so you rarely need them.
Avoid it when your data is highly relational and you run many queries that join across entities, or when you need strong multi row transactional guarantees as the normal case, such as financial ledgers. Heavy analytical reporting across entities also fits a relational or columnar database better.
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
Key-Value Store
The simplest NoSQL model: store data as key-value pairs. Blazing fast lookups by key. Redis, DynamoDB, and etcd are key-value stores.
JSON
JavaScript Object Notation: a lightweight text format for data interchange using key-value pairs and arrays. The lingua franca of web APIs.
Redis
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
Memcached
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
Column-Family Store
A NoSQL database that groups columns into families, optimized for reading and writing large amounts of data across many machines. Cassandra and HBase use this model.
This page explains the idea. The "Document Stores" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Document Stores lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Document Database in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
