关系型数据库通过纵向和横向扩展策略来处理可扩展性，每种策略都有不同的方法。纵向扩展涉及升级单个服务器的硬件（CPU、RAM、存储）以处理增加的负载。例如，运行在 AWS RDS 等云服务上的 PostgreSQL 数据库可以通过迁移到更大的实例类型来纵向扩展。虽然直接，但这种方法有其局限性——硬件成本呈指数级增长，并且物理机器最终会达到性能上限。纵向扩展通常用于短期需求，但对于快速增长的系统来说不可持续。
横向扩展将数据分布在多个服务器上，虽然更复杂，但可以避免单服务器瓶颈。一种常用技术是分片，即将数据分成多个分区（例如，按地理区域划分用户记录或对客户 ID 进行哈希）。例如，一个全球电商平台可以按国家对订单表进行分片以隔离流量。另一种方法是读副本，即数据库的副本处理读查询，而写操作则发送到主服务器。MySQL 的内置复制功能允许开发人员将报告查询分流到副本，从而减轻主节点的压力。然而，横向扩展带来了挑战，例如跨分片维护一致性和处理跨节点事务。
云托管服务通过自动化许多任务来简化扩展。例如，Amazon Aurora 可以自动扩展存储并支持具有低复制延迟的读副本。同样，Google Cloud SQL 提供了自动扩展存储和故障转移功能。开发人员仍必须在设计模式和查询时考虑可扩展性——避免跨分片进行不必要的连接，战略性地使用索引，以及缓存频繁访问的数据。虽然关系型数据库不像 NoSQL 系统那样具有固有的可扩展性，但这些策略如果仔细规划，可以让它们支持大型应用。为了平衡性能和可靠性，通常需要进行权衡，例如最终一致性或增加应用逻辑的复杂性。