Is a document database only for text documents?

No. Its documents are structured records that can contain numbers, dates, nested values and arrays, depending on the implementation.

Does flexible schema mean validation is impossible?

No. Many systems support rules for required fields, types or other conditions while retaining flexibility elsewhere.

Can it support transactions?

Some document databases do, but capabilities and scope differ. Check the specific product and configuration rather than assuming either complete absence or universal support.

AI Glossary / Data engineering and architecture / Intermediate

Document-oriented database

Definition

A document-oriented database stores and queries records as structured documents, commonly containing named fields, nested objects and arrays. It treats a document as a meaningful data unit rather than requiring every record to be represented only as rows in fixed relational tables.

What it means

Document does not necessarily mean a Word file or PDF. Here, it means a structured record such as a customer profile or order, represented in JSON or a related encoding. The database can understand and query fields inside that record.

Documents in a collection may have different fields where the system permits it. This flexibility can suit varied entities, but it does not remove the need for data design. Applications still depend on predictable meanings, types and relationships.

A document database differs from a simple key-value store when it exposes queries and indexes over internal fields. It also differs from a document-management application that primarily handles files and their workflow. Product features vary, so the category alone does not guarantee a particular query language, transaction scope or consistency model.

How it works

Design starts by choosing what belongs in one document. Related values can be embedded together, such as an order and its line items. Alternatively, a document can reference another record by identifier. Embedding can make related data convenient to retrieve, while references can avoid repeatedly copying independently maintained information.

Indexes support common queries, but their structure and cost depend on the fields and access patterns. Optional fields, nested arrays and mixed data types need careful treatment. Schema validation can enforce selected requirements even where the database otherwise allows flexible documents.

Updates follow the product's atomicity and transaction rules. An operation on one document may have different guarantees or costs from an operation spanning several. Size limits and growth also matter: putting an unlimited history into one document can eventually become impractical. Model evolution requires applications to handle old and new record shapes deliberately.

Three practical examples

A product catalog stores common identifiers and names alongside category-specific attributes, such as dimensions for furniture or edition details for books.
An order-processing application keeps a bounded set of line items with the order record because they are usually read together.
An AI evaluation service stores one structured result per test, including input identifiers, model version, scores and reviewer notes, with validation for fields used in reporting.

Think of it this way

Think of a structured case folder that keeps closely related facts together. Different case types may contain different forms, but names, identifiers and important fields still need consistent meanings.

Unlike a physical folder, a database can index fields and update records programmatically. The analogy illustrates grouping and flexibility, not a license to put arbitrary unstructured material together without rules.

Worked example

Consider a fictional order with two line items: three notebooks at 4 credits each and two folders at 5 credits each. An embedded document representation can keep the order identifier and these two items together. Its item total is 3 times 4 plus 2 times 5, or 22 credits.

Suppose the current catalog price of a notebook later rises to 6. If the order should preserve the agreed purchase price, its embedded unit price should remain 4. The catalog can be referenced separately for current product information.

This is intentional historical duplication, not automatically a data error. Conversely, copying a customer's current contact details into many records without an update policy can create inconsistency. The modeling question is which facts represent a transaction-time snapshot and which represent a separately maintained current entity.

Illustrative case study

Fictional case: a training provider stores course documents with an embedded list of all participant activity. Early prototypes work, but active courses accumulate large arrays, making routine updates and retrieval awkward.

The team keeps bounded course details in the course document and moves the growing activity stream into separate records linked by course and participant identifiers. It adds validation for event types and timestamps and checks queries using realistic course sizes.

For published course descriptions, it explicitly versions the structure so older documents remain readable. The case illustrates that a flexible model still needs boundaries, access-pattern analysis and change management.

Common misconceptions and mistakes

Common mistakes include interpreting flexible schema as no schema, assuming every related record should be embedded, and treating all duplicated data as either automatically good or automatically bad. The meaning and lifetime of the copied fact determine the trade-off.

Another mistake is storing numeric values sometimes as numbers and sometimes as text without a deliberate reason. Sorting, filtering and aggregation can then behave unexpectedly. Finally, adopting a document database does not remove the need to consider indexes, permissions, migrations and transactional correctness.

Business use

A business should compare the document model with its main access patterns. It can be useful when related information is naturally retrieved together or entity types have legitimately different attributes. It can be less convenient when the workload frequently combines many independently changing relationships.

For AI systems, structured documents can retain provenance and evaluation detail around generated outputs. That storage format does not validate the content of the output. Separate factual review from schema validation: a result can have every required field and still contain a false answer.

Check your understanding

An old order stores the price agreed at purchase time, which differs from today's product-catalog price. Must the order be updated to match the catalog?

Answer: Not if the stored price intentionally represents the historical agreement. Define whether each field is a snapshot or a reference to current information before treating the difference as an error.

Related terms

Embedding
Indexing
Data Modeling
Document model
JSON
BSON
references
schema validation
denormalisation
schema evolution

Learn next

compare embedding and referencing using one real access pattern. Then study schema validation and index design. Trace what should happen when a shared entity changes and when an embedded collection grows, since those cases reveal weaknesses in an initial document model.

Embedding

Sources

MongoDB, Data Modeling: https://www.mongodb.com/docs/manual/data-modeling/ . Primary documentation of flexible documents and relationship modelling. MongoDB, Embedded Data in Your Schema: https://www.mongodb.com/docs/manual/data-modeling/embedding/ . Primary discussion of grouping related data and embedding limits. MongoDB, Schema Validation: https://www.mongodb.com/docs/manual/core/schema-validation/ . Primary documentation illustrating that document flexibility can coexist with validation. These are implementation examples, not universal promises for every document database.

Previous: Document clustering Next: Document partitioning