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

Don't Panic - Document Databases

A document database keeps a record as one named bundle of values, nested objects, and arrays. Think of an order with its status, delivery address, and line items in one place. It exists because applications often handle those pieces together, while pulling them apart into several records can make every ordinary read feel like a small archaeology project.

The useful idea is the aggregate, not JSON with a new hat. An aggregate is the data an application reads and changes as one boundary. JSON supplies objects, arrays, and scalar values. A database may store something JSON-like instead, with its own types and limits, because databases enjoy adding footnotes to otherwise pleasant nouns.

The first hard choice is embedding versus a reference. Embed a bounded value owned by one parent and usually read with it. An order can embed the delivery address used at purchase, so a later customer profile change does not rewrite history. Reference an entity with an independent lifecycle, such as the customer. Do not embed every order inside one customer document unless the plan is to discover, at an inconvenient moment, that history has no natural stopping point.

Flexible schema does not mean no schema. A collection may accept documents with different fields, but the application still needs stable names, types, required values, and version rules. Validation and migration rules keep controlled variation from becoming a collection of nearly identical field names that have quietly become rivals.

Indexes and partition keys are the second ambush. An index is an extra access path for a frequent filter or sort, not a decorative label for a collection. It speeds selected reads but costs storage and write work. A partition key decides where a document belongs in a distributed store. One attractive value that receives most traffic is still one hot partition, even when many machines are waiting politely nearby.

The final surprise is that document databases do not share one consistency story. A single-document write can be atomic in MongoDB. CouchDB uses revisions and can expose conflicts that the application must resolve. Products differ on transactions, replication, and visibility. The category name is a signpost, not a guarantee.

Read the Intro when you need the full mental model. Use Slides to compare the design choices quickly. Keep the Cheatsheet nearby when reviewing an aggregate, index, or partition key. Then use the practice reference to turn one workload into explicit boundaries and tests. The database is only storing documents. The difficult part is deciding which facts belong together, which must stay apart, and how the answers survive real traffic.

Don't Panic - Document Databases

Relevant careers