共享磁盘故障切换只保留数据库的一份拷贝，从而避免了同步开销。它使用一个由多台服务器共享的磁盘阵列。 如果主数据库服务器失效，备库服务器能够挂载并启动数据库，就像从一次数据库崩溃中恢复一样。这样可以实现快速故障切换且不丢失数据。

共享硬件功能在网络存储设备中很常见。使用网络文件系统也是可行的，但必须注意该文件系统具有完整的 POSIX 行为（见第 17.2.1 节）。这种方法的一个重要局限是，如果共享磁盘阵列失效或损坏，主库和备库都无法工作。另一个问题是，当主库运行时，备库绝不能访问共享存储。

共享硬件功能的一个修改版本是文件系统复制，即对一个文件系统的所有更改都被镜像到另一台计算机上的文件系统。唯一的限制是，镜像的进行方式必须确保备库服务器拥有该文件系统的一致副本 — 具体来说，对备库的写入必须与主库上的写入按相同顺序进行。DRBD 是 Linux 上一种流行的文件系统复制方案。

温备服务器（见第 24.4 节）可以通过读取预写式日志（WAL）记录流来保持最新。如果主库失效，温备几乎拥有主库的全部数据，并且可以被快速提升为新的主数据库服务器。这种方式是异步的，而且只能对整个数据库服务器进行。

主-从复制设置把所有数据修改查询都发送到主服务器。主服务器异步地把数据更改发送到从服务器。在主服务器运行的同时，从服务器可以回答只读查询。从服务器非常适合数据仓库类查询。

Slony-I 是这类复制的一个例子，它具有按表的粒度，并支持多个从库。由于它异步（分批）地更新从库，故障切换期间可能丢失数据。

使用基于语句的复制中间件时，一个程序拦截每条 SQL 查询并将其发送到一台或所有服务器。每台服务器独立运行。读写查询被发送到所有服务器，而只读查询可以只发送到一台服务器，从而分散读取负载。

如果查询只是简单地原样广播，那么像 random()、CURRENT_TIMESTAMP 和序列这样的函数在不同服务器上会得到不同的值。这是因为每台服务器独立运行，而且广播的是 SQL 查询（而不是实际被修改的行）。如果这一点不可接受，中间件或应用就必须从单一服务器查询这类值，然后在写查询中使用这些值。此外，还必须注意让所有事务在所有服务器上要么提交要么中止，或许需要使用两阶段提交（PREPARE TRANSACTION和COMMIT PREPARED）。Pgpool-II 和 Sequoia 是这类复制的例子。

对于不经常连接的服务器，例如笔记本电脑或远程服务器，在服务器之间保持数据一致是一个挑战。使用异步多主复制时，每台服务器独立工作，并定期与其他服务器通信以识别冲突的事务。冲突可以由用户或冲突解决规则来处理。Bucardo 是这类复制的一个例子。

在同步多主复制中，每台服务器都可以接受写请求，被修改的数据在每个事务提交之前从原始服务器传送到其他所有服务器。繁重的写活动可能导致过度的锁竞争，从而使性能变差。事实上，写性能往往比单一服务器还差。读请求可以发送到任意服务器。有些实现使用共享磁盘来降低通信开销。同步多主复制最适合以读为主的负载，不过它的一大优势是任何服务器都可以接受写请求 — 无需在主从服务器之间划分负载，而且由于数据更改是从一台服务器发送到另一台的，像 random() 这样的非确定性函数也不会有问题。

PostgreSQL 不提供这种类型的复制，不过 PostgreSQL 的两阶段提交（PREPARE TRANSACTION和COMMIT PREPARED）可以在应用代码或中间件中用来实现它。

由于 PostgreSQL 是开源且易于扩展的，许多公司基于 PostgreSQL 创建了具有独特故障切换、复制和负载均衡能力的商业闭源方案。

数据分区把表拆分成多个数据集。每个数据集只能被一台服务器修改。例如，数据可以按办公室分区，比如伦敦和巴黎，每个办公室有一台服务器。如果需要组合伦敦和巴黎数据的查询，应用可以查询两台服务器，或者使用主/从复制在每台服务器上保留另一个办公室数据的只读副本。

上面的许多方案允许多台服务器处理多个查询，但没有一种允许单个查询使用多台服务器来更快地完成。这种方案允许多台服务器并发地处理单个查询。它通常通过在服务器之间拆分数据，让每台服务器执行查询中属于自己的部分并把结果返回到一台中央服务器，在那里合并后返回给用户来实现。Pgpool-II 具有这种能力。此外，也可以使用 PL/Proxy 工具集来实现。