数据库集群和数据库复制都是提高性能和可靠性的策略，但它们的工作方式不同。 集群涉及将多个数据库实例分组，作为一个系统协同工作，通常共享存储或协调任务以集体处理请求。 复制侧重于将数据从一个数据库（主数据库）复制到一个或多个辅助数据库，并保持它们的同步。 集群旨在通过统一的系统提供高可用性和可伸缩性，而复制则通过维护副本来优先考虑数据冗余和读取可伸缩性。
在集群数据库中，节点（单个数据库实例）协同工作以分配工作负载或提供故障转移支持。 例如，使用流复制和共享无关架构的 PostgreSQL 集群可能会跨节点拆分数据，每个节点处理一部分查询。 如果一个节点发生故障，其他节点可以接管它的工作负载。 集群通常需要专门的配置，例如 MySQL Cluster 的 NDB 存储引擎，该引擎在节点之间同步内存中的数据以实现实时一致性。 集群通常在内部管理负载平衡、自动故障转移和事务协调等任务，使它们对应用程序来说看起来像一个单一的逻辑数据库。 这种设置对于停机时间是不可接受的高吞吐量系统（例如金融交易平台）非常有用。
相比之下，复制会在单独的数据库之间创建数据副本。 一个常见的例子是 MySQL 的主从复制，其中主数据库处理写入并异步地将更改传播到只读副本。 副本可以服务于读取查询，从而减少主数据库上的负载。 与集群不同，副本通常在地理上是分布式的（例如，美国的主数据库和欧洲和亚洲的副本）以减少用户的延迟。 但是，复制引入了最终一致性——副本可能会滞后于主数据库。 某些系统（例如 MongoDB 的副本集）允许通过将副本提升为主数据库来自动进行故障转移（如果原始数据库发生故障）。 复制更易于实现，可用于扩展读取或灾难恢复，但不像集群那样固有地分配写入工作负载。 开发人员可能会将两者结合起来：使用复制进行备份和读取扩展，而集群处理写入密集型任务。