我们使用 Postgres 构建多租户 SaaS 服务时踩的坑

原文 Our Multi-tenancy Journey with Postgres Schemas and Apartment。这篇和之前发出的「如何使用 Postgres 对一个多租户应用分片」相呼应。

多租户 (Multip-tenancy) 是当下的热门话题。我对多租户应用程序的定义是一个能够服务于多个客户的软件系统，每个客户都能在该系统中拥有自己数据的独立视图。每个客户及其数据通常被称为一个租户，因此而有了多租户之名。

在早先关于分片多租户应用程序的博客文章中，Craig 深入探讨了任何需要支持多个客户账户的系统中自然发生的租户类型（或在他的例子中，是一家店）。在他的例子中，属于特定租户的所有记录都会获得一个外键 tenant_id，这个键逻辑上将其他表中的行与该租户关联起来。隔离发生在查询级别，比如所有产品（例如）都会使用 tenant_id 来限定范围，针对你感兴趣的特定商店。

当我加入 Influitive 时，他们已经采用了多租户路线，但是使用了PostgreSQL schema 来隔离。这使用了一种略有不同的多租户机制，其中表不再存储对其租户的引用。相反，当我们添加一个新租户时，我们会创建一个新的 Postgres schema，并在该 schema 内创建（复制）所有存储客户数据的表。为一个租户进行的查询设置了 schema search_path，以便所有为该请求获取的数据现在都隐式地限定在该租户范围内。