许多应用程序仅在单一区域运行，无需分布式处理。但对于拥有全球客户群的应用程序，分布式数据管理可以提供显著的性能和可用性优势。本文提出的模式在满足两个条件时适用：一是应用程序数据可以按租户（tenant）分段，二是租户数据具有特定区域的亲和性。
以一个类似Notion的多租户SaaS服务为例，其数据（页面、块、表格、评论、文件、编辑历史等）可以按工作空间（workspace）分隔，每个工作空间即为一个租户。这些数据在租户内部是关联的，但不同租户间不存在外键关联。此外，控制平面（control plane）数据，如用户表、工作空间列表和用户与工作空间的成员关系，不需要分段。
在此模式下，控制平面数据表保留在单一中心区域，而租户数据则分布到与租户亲和的区域。由于数据按租户分段，所有外键都指向租户内部，因此连接到单一区域即可访问特定租户的所有数据。这意味着登录和注册操作可能稍慢，因为它们是从中心区域提供的，但这些操作相对较少。
每个区域都部署了应用程序堆栈的副本。登录/注册后，使用JWT（或其他类似令牌）进行数据平面的身份验证。这样，每个后续请求都可以直接发送到存储租户数据的区域。
此外，应用程序堆栈可以在边缘平台（如CloudFlare workers）上运行，从而自动靠近用户并（希望）靠近租户区域。在这种情况下，客户端可以将租户区域作为请求的一部分传递，边缘平台可以将请求路由到正确的区域。
通过使用postgres_fdw扩展（随默认PostgreSQL安装提供），可以在控制器节点上创建一个全局视图，该视图看起来像一个普通的PostgreSQL表，但实际上是一个聚合了多个PostgreSQL实例数据的视图。
尽管FDW + 分区技巧提供了一个可以查询和写入的全局视图，但目前还存在一些重要的限制。例如，跨区域的写事务不是ACID的，因为当前的PostgreSQL FDW不支持两阶段提交（2PC）或其他确保事务在所有节点上原子性的机制。
只要不经常需要同时访问或写入多个租户的数据，这种模式就非常适用，这通常是多租户SaaS应用程序的情况。随着PostgreSQL FDW、分区和规划器的改进，我们可以期待全局视图的性能提升，使这种模式适用于更广泛的应用程序。未来，为了实现分布式PostgreSQL，您可能不需要使用像Citus这样的扩展，而是可以使用标准的PostgreSQL代码。