为什么我们为每租户SQL Server隔离多付钱

如果您读过足够多的多租户SaaS架构文章，您会注意到它们都以相同的方式开始：如果您的工程师有纪律，行级安全是可以的；每租户数据库是过度工程化的，直到您有合规原因。含义是您应该默认行级安全，并在企业采购团队强制您时升级到隔离。

这个框架假设稍后切换的成本很小。在货运中不是。进行每租户隔离重要的采购团队——SOC 2 Type II审查、ISO 27001审计、Fortune 500供应商安全问卷——从对话的第一天开始到达，而不是在第三年。如果您对"您如何分离租户数据"的回答是多段和有条件的，您已经失去了这次会议。

所以我们从前面做出了更昂贵的选择。

PulseCargo实际做什么

每个租户都得到自己的SQL Server数据库。命名很乏味：

• PulseCargoDb — 门户数据库，持有租户身份、计费计划、服务协议、门户管理员帐户和跨租户基础设施。
• PulseCargo__<tenant-slug> — 每个客户租户一个，持有该租户的所有客户数据：货物、订单、集装箱、海关条目、发票、文件、审计日志、AI查询日志。

Web层、API层和后台工作人员通过TenantResolutionMiddleware在每个请求中接收租户标识符。中间件查找租户slug，为该租户的数据库计算连接字符串，并将该连接绑定到请求范围。请求中的每个数据库调用——无论是通过Entity Framework Core、Dapper还是直接ADO——都使用该绑定连接。

一个没有租户范围的查询无法连接到租户数据库。没有共享表忘记WHERE子句。被遗忘的WHERE子句故障模式——在共享模式SaaS中跨租户数据泄露的最常见原因——在我们的代码库中不存在。

我们接受的权衡

这在四个特定方面比行级隔离更昂贵。每一个都是真实的，每一个都是我们会再做一次的。

每个客户的存储成本更高。每个租户数据库都有自己的索引、事务日志、统计数据和开销。小租户的边际成本比在共享模式模型中会更高。我们为此付费。它线性扩展。跨租户数据泄露的成本不会线性扩展——它按供应商想留在企业中的程度扩展。

跨租户分析更费工作。我们在Professional层级提供的聚合行业基准作为选择加入功能需要迭代参与租户、计算每个租户统计数据，并将聚合写入专用基准存储。大多数共享模式供应商免费获得廉价聚合。我们支付这个成本作为一次性每日后台工作。好处是聚合在构造上是k-匿名的（k ≥ 5），并且租户通过明确标志选择加入，而不是发现他们的数据已经在一堆中。

配置需要更多步骤。新租户需要数据库创建、模式迁移、启动包导入和EF迁移历史回填。我们有一个脚本（scripts/backfill-tenant-ef-history.ps1）和一个配置管道来自动化这个；它大约是一个两分钟的步骤。不是免费的，但不是痛苦的。

模式迁移按数据库应用。模式变化必须应用在每个租户数据库中，而不仅仅是一个。EF Core迁移在部署时按租户应用，带有回滚路径。纪律成本是真实的，但部署管道透明地处理它。

总运营成本：在我们当前的租户计数处，大约是共享模式成本的1.5倍到2倍，随着租户数的增长渐进地收敛到大约1.2倍。

回报——隔离为您购买什么

隔离购买的一些东西很明显。一些不是。

被遗忘的WHERE子句类的bug不存在。一个新查询、一个重构、一个存储过程迁移、一个初级工程师的第一个PR——没有一个可以跨租户泄露数据，因为没有共享表忘记谓词。ORM过滤器绕过通过原始SQL？同样的答案。缓存密钥重用？同样的答案。

后台工作不能没有指定租户就拉"所有行"。这个工作必须询问它为哪个租户运行，以便获得连接字符串。默认是"没有连接"。

直接连接的BI工具由凭证绑定的租户。Power BI Embedded使用每个租户工作区凭证。即使BI顾问尝试做一些异国情调的事情，他们有访问权限的凭证在数据库层按租户范围。

备份默认按租户范围。每个租户都有自己的备份文件。恢复到错误的地方不是"要小心"问题；它是"不会连接"问题。

合规审计答案是一个句子。"您如何分离租户数据？" "每个租户都有自己的SQL Server数据库，由中间件解析。一个租户的连接字符串无法到达另一个租户的数据库。"那是整个答案。合规审计人员在五分钟内注意到它。

我们自己运行的审计

在2026-04-24，我们对代码库运行了全面的租户隔离审计。61个控制器，大约140个端点，每个数据库查询路径。我们特别寻找跨租户数据暴露：一个租户可能通过API行为不端、通过查询注入或通过共享状态bug看到另一个租户数据的地方。

零CRITICAL发现。

确定了一个INFO级别发现：并非所有第三方服务（Stripe Connect、TMS提供商探针、AI提供商）都没有实现出站集成审计日志。这是一个SOC 2 CC4.1 / CC7.2证据差距，不是跨租户暴露。该模式对eAdaptor就位；其余服务在构建队列中。我们在安全文档中诚实地表面这个差距，而不是在SOC 2证据审查期间发现它。

完整审计报告可根据安全团队的要求共享。（电子邮件security@pulsecargo.ai。）

这不是什么

每租户数据库隔离不是其余安全状态的替代品。这是基底。AES-256静态加密、TLS 1.3传输中、本地MFA + SSO、RBAC、每项操作的审计日志、GDPR / CCPA自助服务端点、带有经过测试的重水化的软件托管——所有这些仍然必须运输，并且必须做得正确。隔离只是意味着下面的所有那个不具有漏洞。

这也不是一个吹牛。有令人信服的理由运送共享模式多租户——水平规模、成本纪律、更简单的ops——许多很好的SaaS产品以这种方式运行。我们选择不同，因为我们市场中的买家注意到，成本差异是有界的，而获得它的最坏情况的缺点是无界的。

如果您是评估PulseCargo的货运代理，问这个问题。问您评估中的每个供应商。谁能在一个句子中回答它可能是更安全的供应商。

---

想要更深层版本？每租户数据库隔离架构白皮书为安全团队和采购审核人员扩展这篇文章中的每个要点。完整的租户隔离审计报告可根据请求共享——电子邮件security@pulsecargo.ai。

这是"深入PulseCargo"技术内容系列的第一篇。我们将每月发布其中一篇，详述塑造产品的工程决策。接下来：当基础语言模型被共享时，综合智能检索层如何保持租户背景分离。