集群数据库与单节点数据库相比有多个优点，但费用和复杂性更高。除此之外，集群数据库还有更高的可用性、更高的吞吐量，在一些情况下还有更低的延迟。
对于每个节点都有整个数据库副本的集群而言，你可以获得更高的冗余性和更高的可用性。视策略而定，读取操作可能只需要一个节点，否则集群中的一组节点可能需要就返回值达成一致。
使用有多个节点的集群可以让数据库使用更多的CPU，从而增加吞吐量，并提高事务率。使用允许最近节点返回值的读取策略，读取延迟通常会降低。另一方面，必须等待所有节点提交的写入或事务策略，有时会增加写入延迟。
使用共识组有助于缩短延迟。如果你有一个三节点集群，一个节点负载过大，另两个节点就可以批准共识事务，并在第三个节点可用时更新该节点。
分片是一种通过划分数据库来处理更多数据的方法。手动分片可能费时又麻烦，许多数据库都有自动分片功能。
集群不是扩展数据库的终极方法，不过是第一步。下一步是分布式数据库，这通常意味着在多个区域有集群。一些数据库允许分布式只读副本和主读写实例或集群。其他数据库允许分布式读写实例或集群，并具有同步机制。
分布式数据库常常可以为远程用户提供更低的延迟和更高的吞吐量。东京的用户访问巴塞罗那的服务器可能会有260 毫秒的延迟，但如果日本有数据库副本，他们的平均读取延迟可能只有10毫秒。这对写入和事务的影响取决于数据库的一致性要求以及远程集群是如何配置的。
早期的分布式数据库是具有最终一致性的NoSQL数据库。最终一致性意味着不能保证在远程位置写入后读取返回最新信息，但会随着时间而更新。最终一致性放宽了写入和事务完成的要求，因而降低了延迟。
最近几种分布式数据库在数据结构、共识组和时间同步的帮助下实现了强一致性。这方面的例子包括Google Cloud Spanner和CockroachDB。
虽然大多数数据库都有免费的"社区"或"开发/测试"版本，但除了在线社区论坛外，它们可能缺乏支持。社区版和开源版也可能缺乏商业版本提供的一些性能优化。如果贵公司依赖数据库，应在许可证和支持上投入成本。
如果你在云端运行数据库，至少需要为云资源付费。如果是商业数据库，你还需要数据库许可证，这可能是来自供应商的长期许可证，也可能是通过云提供商购买的按需付费许可证。
CAP定理（Brewer 等人于1998 年提出）声称，任何网络共享数据系统最多具有以下三个理想属性中的两个：
C：一致性，相当于拥有一个最新的数据副本；
A：该数据的可用性，用于更新；
P：对网络分区的容忍度。
数据库的理想属性取决于它所服务的应用的需求。如果该应用显示目录，那么数据库的读取速度和延迟很重要，文档数据库可能很理想，但关系数据库和宽列数据库也适用。如果该应用处理金融交易，那么数据库的ACID属性（原子性、一致性、隔离性和持久性）就很重要，关系数据库可能很理想。
