A document database is a NoSQL data model that stores each record as a self-contained document rather than as a row spread across relational tables. The document is typically encoded in a structured format such as JSON, the binary BSON used by MongoDB, or XML. MongoDB’s documentation describes a document as a data structure composed of field and value pairs, similar to a JSON object, whose field values may themselves include other documents, arrays, and arrays of documents.
The defining trait is a flexible, nested schema. Because each document carries its own structure, related data can be embedded inside a single record, and two documents in the same collection need not have the same fields. This makes documents map closely to the objects an application already works with in code, reducing the impedance mismatch between program data and stored data, and often removing the need for the joins that a relational design would require.
That flexibility comes at a cost. Document stores generally do not enforce the relational integrity constraints, such as foreign keys and normalized tables, that relational databases provide. Data that is duplicated across embedded documents can drift out of sync, and the schema discipline that a relational system imposes becomes the application’s responsibility.
Apache CouchDB is another firsthand example: its own site notes that it speaks JSON natively, storing each record as a JSON document and exposing them over HTTP. Document databases such as MongoDB and CouchDB were central to the NoSQL movement, offering developers a way to persist application objects directly instead of decomposing them into tables.