How do document databases store data?

Document databases store data as flexible, self-contained documents rather than in rigid tables with fixed schemas. These documents typically use formats like JSON or BSON (Binary JSON) and group related data into a single hierarchical structure. Each document contains key-value pairs, arrays, or nested objects, allowing developers to model data in a way that closely aligns with application logic. For example, a user profile document might include fields like username, email, and address, where address itself is a nested object containing street, city, and zip_code. Documents are stored in collections, which act as containers but don’t enforce uniform schemas—each document in a collection can have different fields or structures.

A key difference from relational databases is that document databases avoid normalization. Instead of splitting data across multiple tables linked by foreign keys, they embed related data directly within a document. For instance, an e-commerce product document might include an array of customer reviews as nested objects, eliminating the need for a separate “reviews” table. This approach simplifies read operations, as fetching a single document retrieves all associated data in one query. Databases like MongoDB use BSON to efficiently store and query these structures, supporting data types like dates and binary data that plain JSON lacks. Indexes can be created on specific fields (e.g., product_id) to speed up queries, even within nested structures.

Document databases excel in scenarios requiring flexibility or handling semi-structured data. Applications like content management systems or real-time analytics benefit because fields can be added or modified without schema migrations. Scalability is achieved through horizontal partitioning (sharding), where documents are distributed across servers based on a shard key, such as a user’s geographic region. However, this flexibility comes with trade-offs: complex transactions spanning multiple documents may require application-level handling, though some databases now support ACID transactions for limited cases. Developers choose document databases when their data models evolve frequently or when read/write patterns favor localized, hierarchical data access over complex joins.