Document Databases
Document databases store data as semi-structured documents — typically JSON or BSON — rather than fixed rows and columns. They support flexible schemas, nested structures, and queries within documents, suiting workloads where data shapes vary or evolve frequently.
itDatabases and data storage | OpenSkills.info
Intro
Document Databases
A document database stores each record as a document: a self-contained group of named fields and values. A document can contain strings, numbers, Boolean values, null values, nested objects, and arrays. Many products use JSON or a JSON-like format. MongoDB, for example, stores BSON documents, which extend the JSON model with additional data types.
The useful idea is not "JSON instead of tables." It is the aggregate: data that your application reads and changes together can live together. An order document can contain its delivery address and line items. One read can retrieve the order as a complete unit. One single-document write can change several fields atomically in systems that provide document-level atomicity.
That shape can reduce joins and let related fields evolve together. It also moves important design decisions into the document boundary. You still design a schema, even when the database does not require every document to have identical fields.
Why document databases exist
Relational databases organize data into tables and use relationships between rows. That model is strong when shared facts must stay normalized and queries combine data in many ways. It can be awkward when an application usually loads one nested object and must reconstruct it from several tables.
A document database makes the stored record resemble the object or message used by the application. This can help when:
- one entity owns a bounded set of nested data;
- records of the same broad type have optional or varying fields;
- the application usually reads an entire aggregate by its identifier;
- development requires controlled schema evolution;
- data must distribute across partitions for horizontal scale.
These are tendencies, not guarantees. Products differ in query languages, index types, transaction scope, validation, replication, and consistency. Verify the behavior of the product and deployment you select.
The document mental model
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://datatracker.ietf.org/doc/html/rfc8259
Supports
- JSON as a text interchange format
- Objects as unordered name-and-value pairs
- Arrays as ordered values
- JSON primitive values and UTF-8 interoperability guidance
- JSON standards link rationale
- https://www.mongodb.com/docs/manual/core/document/
Supports
- BSON documents as field-and-value records
- Nested documents and arrays
- BSON as a binary representation with types beyond JSON
- MongoDB documents link rationale
- https://www.mongodb.com/docs/manual/data-modeling/embedding/
Supports
- Embedded objects and arrays
- Retrieval of related data in one operation
- Single-document atomic update benefit
- Ownership-oriented embedding cases and document size limit
- Embedding link rationale and related quiz answers
- https://www.mongodb.com/docs/manual/data-modeling/referencing/
Supports
- References between independently stored documents
- Reference cases for changing data, many-to-many relationships, large hierarchies, and independent queries
- Normalization and duplication tradeoffs
- Reference link rationale and related quiz answers
- https://www.mongodb.com/docs/manual/core/indexes/index-types/
Supports
- Single-field, compound, multikey, wildcard, geospatial, hashed, and text index categories
- Index types link rationale
- https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/create-compound-index/
Supports
- Compound index field order and leading-prefix behavior
- Compound-index quiz answer
- https://www.mongodb.com/docs/manual/core/write-operations-atomicity/
Supports
- Single-document write atomicity
- Multi-document transaction availability
- Additional cost of distributed transactions
- Schema design as a way to reduce broad transaction needs
- Atomicity link rationale and related quiz answers
- https://www.mongodb.com/docs/manual/core/schema-validation/handle-invalid-documents/
Supports
- Rejecting invalid writes by default
- Warning while allowing invalid writes
- Validation during migrations
- Flexible-schema quiz answer
- https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning
Supports
- Logical partitions grouped by partition-key value
- Hash mapping of logical to physical partitions
- Even throughput distribution and hot-partition risk
- Cross-partition query cost and transaction boundaries
- Partitioning link rationale and related quiz answer
- https://docs.couchdb.org/en/stable/intro/overview.html
Supports
- Multi-version concurrency control
- Atomic single-document updates
- Integrated document, query, and replication model
- CouchDB overview link rationale
- https://docs.couchdb.org/en/stable/replication/conflicts.html
Supports
- Revision identifiers and stale-write conflict response on one node
- Competing revision branches introduced through replication
- Application responsibility for conflict resolution
- Conflict-model link rationale and related quiz answer