分布式数据库使用一致性模型来定义数据何时以及如何在不同节点间可见。三种主要模型是强一致性、最终一致性和因果一致性，还有诸如会话一致性和顺序一致性等变体，用于解决特定的用例。每种模型都在数据准确性、系统性能和可用性之间进行权衡。
强一致性确保所有节点同时看到相同的数据。当写操作完成时，后续从任何节点读取都将返回更新后的值。该模型优先考虑数据准确性而非性能，通常使用两阶段提交或分布式事务等协议来协调更新。例如，金融系统（如银行应用）需要强一致性来防止双重支付或错误的余额。然而，这会带来更高的延迟，因为节点在确认写入之前必须进行同步。Google Spanner 和传统关系型数据库等系统通常实现强一致性。
最终一致性允许节点之间存在暂时的差异，保证在没有新的更新发生时，所有副本最终会收敛到同一状态。该模型优先考虑可用性和分区容错性，适用于低延迟至关重要的系统。社交媒体平台（如 Twitter 或 Instagram）对点赞或评论等功能使用最终一致性，其中传播中的微小延迟是可以接受的。Amazon DynamoDB 和 Apache Cassandra 支持这种模型，使用诸如暗示移交（hinted handoffs）或读修复（read-repair）等机制来解决冲突。然而，开发者必须处理在收敛窗口期间可能读取到陈旧数据的场景。
因果一致性及其变体解决了特定需求。因果一致性确保因果相关的操作（例如，对帖子的回复）按正确顺序可见，即使不相关的操作可能乱序出现。这在 Google Docs 等协作应用中非常有用，其中编辑依赖于先前的更改。会话一致性保证用户在单个会话（例如，购物车）中的交互保持一致，即使其他用户看到的是陈旧数据。顺序一致性确保所有节点对操作的顺序达成一致，这在分布式队列或日志中很有用。单调读（Monotonic reads）是一种较弱的模型，它确保客户端一旦读取某个值，后续读取永远不会看到更旧的数据。这些模型为开发者提供了灵活性，可以优先考虑一致性的特定方面，而无需承担强一致性的开销。