Document Database
A document database stores data as self-contained documents (typically JSON or BSON) grouped into collections, instead of as rows in tables with strict schemas. Each document carries its own structure, allowing fields to vary across documents in the same collection.
Why document storage
- Schema flexibility. Fields can be added without migrations; documents in the same collection can have different shapes.
- Locality. Related data (an order plus its line items) can live in one document instead of spanning many tables, simplifying reads.
- Developer ergonomics. Documents map directly to objects in most programming languages.
Common engines
- MongoDB. The category leader; BSON documents, aggregation pipeline, change streams, sharding, replica sets.
- Couchbase. Document store with N1QL query language and built-in full-text and analytics services.
- Firestore. Google's hosted document database with real-time sync for mobile and web clients.
- DynamoDB. AWS-managed key-value and document store with single-digit-millisecond latency at any scale.
- Cosmos DB. Microsoft's multi-API database; supports document via the SQL and MongoDB APIs.
- PostgreSQL JSONB. Many teams use JSONB columns in Postgres rather than adopting a separate document database.
Common considerations
- Index the access patterns; flexible schema is not a substitute for query planning.
- Document size limits (typically 16 MB) constrain extreme denormalization.
- Joins are usually weaker than in relational databases; model access patterns first.
🔗
📖