Document Databases: Store Data as Flexible Objects

Why it exists

Relational databases require a predefined, rigid schema. Adding a new field means altering a table for all rows, which is slow for applications with evolving data models. Document databases were created to handle this semi-structured data natively, matching the object-oriented nature of modern applications without forcing data into rows and columns.

The mental model

Instead of a spreadsheet-like grid, imagine a collection of individual files in a folder. Each file (a "document") is a self-contained unit of information, typically in a format like JSON. A document for one user might have a phone_number field, while another might not. The database doesn't enforce uniformity; it just stores the whole document and lets you query for documents based on the fields inside them.

How it works

Data is stored in collections of documents, and each document has a unique ID. A document is a set of key-value pairs where values can be simple types (strings, numbers), arrays, or even other nested documents. Instead of complex JOINs, you often embed related data directly within a single document to retrieve it all in one operation. The database creates indexes on specified fields to make queries fast.

When to use it

Use a document database for content management systems, user profiles with custom fields, e-commerce catalogs with diverse attributes, and IoT applications. It's a strong choice when your data model is likely to evolve or when all data for a single logical entity is best retrieved at once. It maps very cleanly to objects in languages like JavaScript, Python, and Java.

When not to use it

Avoid document databases for highly relational data that requires complex, multi-table JOINs and strict transactional guarantees, like in a traditional financial system. If your data fits neatly into tables and its structure is stable, a relational database is often more efficient and ensures better data integrity through its rigid schema.

One canonical example

A user profile in MongoDB might be a single JSON document: { "_id": "123", "username": "alex", "interests": ["hiking", "coding"], "profile_details": { "city": "San Francisco" } }. Another user's document could have a different structure entirely, like including a work object, and the database handles both without issue.