文档数据库将数据存储为灵活的、自包含的文档，而不是使用具有固定模式的刚性表。这些文档通常使用 JSON 或 BSON (二进制 JSON) 等格式，并将相关数据分组到单个分层结构中。 每个文档包含键值对、数组或嵌套对象，允许开发人员以与应用程序逻辑紧密对齐的方式建模数据。 例如，用户个人资料文档可能包含诸如 username、email 和 address 等字段，其中 address 本身是一个包含 street、city 和 zip_code 的嵌套对象。 文档存储在集合中，集合充当容器，但不强制执行统一模式——集合中的每个文档可以具有不同的字段或结构。
与关系数据库的主要区别在于，文档数据库避免规范化。它们不是将数据拆分到由外键链接的多个表中，而是将相关数据直接嵌入到文档中。例如，电子商务产品文档可能包含作为嵌套对象的客户评论数组，从而无需单独的“评论”表。 这种方法简化了读取操作，因为获取单个文档会通过一个查询检索所有关联的数据。 像 MongoDB 这样的数据库使用 BSON 来有效地存储和查询这些结构，支持普通 JSON 缺乏的日期和二进制数据等数据类型。 可以在特定字段（例如，product_id）上创建索引以加速查询，即使在嵌套结构中也是如此。
文档数据库擅长需要灵活性或处理半结构化数据的场景。 诸如内容管理系统或实时分析之类的应用程序受益，因为可以添加或修改字段而无需模式迁移。 可通过水平分区（分片）来实现可扩展性，其中文档基于分片键（例如，用户的地理区域）分布在服务器上。 但是，这种灵活性带来了一些权衡：跨多个文档的复杂事务可能需要应用程序级别的处理，尽管某些数据库现在支持有限情况下的 ACID 事务。 当数据模型经常演变或者读/写模式偏爱本地化的、分层的数据访问而不是复杂的连接时，开发人员会选择文档数据库。