Document Databases

An object is stored as one document

A Document Database stores records as documents — usually structured objects with fields, nested objects, and arrays. One document often represents an aggregate that the application usually reads and changes as a unit.

{
  "id": 42,
  "name": "Alex",
  "addresses": [
    { "city": "Denver", "type": "home" }
  ]
}

Unlike a normalized relational model, related data can be embedded when it shares a lifecycle and is usually needed together.

Flexible structure does not mean chaos

Documents of the same type can have different sets of fields, which is convenient as the model evolves gradually. But the application still needs to understand versions and the allowed data structure.

If a new field is optional, old and new documents can coexist for some time. Incompatible changes still require migrations or logic that can read several versions.

Embed or reference

If data is small, belongs to one aggregate, and is almost always read together, embedding simplifies reads. If an object is large, used independently, or shared across many entities, a separate record and reference may be more convenient.

Too much duplication makes updates harder: one logical value must be synchronized across many documents. Too many references, on the other hand, bring back the need to assemble an object from several requests.

Queries depend on supported indexes

Document databases can usually search not only by identifier but also by document fields, provided the required queries have suitable support and indexes. This makes the model more flexible than key-value access, but query cost still needs to be considered.