我们的 GDPR 合规性和欧盟主权 后端指南列出了完整的法律框架：GDPR、云法案，以及为什么仅检查托管区域是不够的。本文通过每个选项的实际操作负担扩展了中小企业仲裁部分，而不是重述法律理论。如果您的问题涉及自托管 Rust 后端、sh0.dev、TrailBase、Aurabase，我们的专门比较 Aurabase 与 Rust 原生 BaaS 解决了这个独特的架构角度。无论后端语言如何，这仍然集中于中小企业的 GDPR 决策。
要点
- 有两种选项在纸面上符合 GDPR：欧盟自托管和欧盟主权 BaaS：它们的区别在于转移的运营负担，而不是合规性本身。
- 自托管需要一个能够持续修补、备份、监控和记录 Postgres 的团队。这种费用永远不会消失：它只是易手于外部供应商。
- 具有欧盟区域选项的美国 BaaS 只能解决一半的问题：无论选择哪个区域，运营该服务的公司的国籍仍然受到《云法案》的约束。
- 中小企业的首席技术官通常会在内部构建、Supabase Cloud、AWS Amplify 和主权欧盟解决方案之间做出决定：正确的选择首先取决于可用的团队能力。
- Aurabase 涵盖两种模式：欧盟主权管理的 BaaS（Hetzner、德国和芬兰）或通过 Kubernetes（本地 k3d）和 Helm 进行自托管（根据 MIT 许可）。
这两个选项的真正区别是什么
欧洲数据中心的自托管后端和欧盟主权 BaaS 都可以勾选相同的 GDPR 框：欧盟位置、欧洲运营公司、可用的 DPA（提供商方）或最新的内部注册表（自托管方）。 GDPR 在两者之间没有架构偏好。真正改变的是由谁承担日常运营负载：安全补丁、经过测试的备份、随叫随到、持续监督。
完整的法律框架、GDPR 和云法案在我们的 GDPR 合规性和欧盟主权后端指南中进行了详细介绍。本指南没有深入探讨对于不一定有专门的 SRE 的团队来说，每个选项的实际运营成本。这就是本文的角度。
自托管：中小企业必须真正承担什么
自托管 Postgres 后端将完整的运营责任转移给您的团队，而不仅仅是服务器。具体来说，有四项任务会反复出现：Postgres 安全补丁发布后立即应用，定期测试备份恢复，而不仅仅是安排它。还需要持续监控可用性，或接受更长的响应时间，并根据记录的时间表轮换秘密和访问密钥。
即使在自托管中，这些任务也永远不会消失。相对于您的主机（Hetzner、OVH、Scaleway 或其他），您仍然是自己的技术分包商。 DPA 必须同时存在，并且您的处理登记册（GDPR 第 30 条）必须记录该链。没有专门的基础设施团队的中小企业通常会低估最后一点。
欧盟主权BaaS：什么被转移，什么仍然是你的
欧盟主权 BaaS 在已注明日期且可验证的 DPA 的保护下，将补丁、备份基础设施和可用性监控转移给提供商（GDPR 第 28 条）。易手的是前一点所述的运营负担，而不是法律责任。
无论选择哪个供应商，数据控制者仍然是您（GDPR 第 24 条）。处理的法律依据、最大限度地减少收集的数据、在 72 小时内向监管机构通知违规行为（GDPR 第 33 条）：这些决定仍然由您负责。欧盟主权 BaaS 缩短了向 DPO 或客户提供合规证明所需的时间。它不会免除您拥有一个的义务。
我们经常忘记的第三个选择：美国 BaaS、欧盟地区
许多团队只比较两个选项，而第三个选项会在他们真正的决定中权衡：超大规模或根据美国法律在欧洲地区配置的 BaaS。 AWS Amplify 具有 eu-west-1区域或同等服务，可减少延迟并满足数据驻留要求。但这并不会改变经营该公司的公司的国籍。
根据美国法律成立的公司仍然受《云法案》的约束，无论其客户选择的区域如何。我们的指南 GDPR 合规性和欧盟主权后端 以及我们的专门文章 为什么云法案会改变您的 BaaS的选择中详细阐述了这一点。它在中小企业的仲裁中很重要，即使这种选择在短期内看起来是最简单的。
自托管、欧盟地区的美国 BaaS、欧盟主权 BaaS：比较
以下是当今中小企业实际可用的三个选项，根据架构决策中最重要的标准进行比较，而不仅仅是选中的区域框。
| 标准 | 自助住宿 欧盟 | 美国 BaaS、欧盟地区 | 欧盟主权BaaS |
|---|---|---|---|
| GDPR 纸面合规性 | 是的，如果有内部记录的话 | 是的，如果有记录的话 | 是的，如果有记录的话 |
| 云行动展览 | 无效（无第三方美国公司） | 实际（美国母公司） | 无效（欧盟母公司） |
| 修补和值班值班 | 一体式，内部携带 | 转移给供应商 | 转移给供应商 |
| 提供合规证明 | 内部注册维护自己 | DPA 供应商，美国框架 | 供应商 DPA，已注明日期且可验证 |
| 需要基础设施团队 | 建议使用专用 SRE/ops | 单个开发人员，通常就足够了 | 单个开发人员，通常就足够了 |
| 生产速度 | 速度较慢，基础设施有待建设 | 快 | 快 |
自托管从未计入账单的成本
自托管的真实成本无法从服务器账单上看出。它可以在工程师从产品中转移的时间中读取，并且在发生事件时直接法律曝光。
自托管中小企业既成为数据控制者，又成为自己的技术分包商。丢失的 Postgres 补丁或从未测试过的备份可直接归因于数据控制者本人（GDPR 第 83 条），而没有 DPA 合同链来反对文件尽职调查。对于一家欧盟主权 BaaS 提供商来说，同样的失败仍然是一个现实的风险。但这是一份过时合同的一部分，DPO 或审计员可以在几分钟内验证，而不是在需要重建的内部历史记录中。
当自托管仍然是正确的选择时
自托管对于 ETI 或已经拥有 SRE/运营团队和待命功能的大型帐户仍然具有相关性。对于主权不允许任何外部分包链的部门来说也是如此：公共部门、国防、某些卫生机构。对物理服务器的直接控制优先于生产速度。
与从头开始的中小企业相比，已经投资了内部 Kubernetes 或 Postgres 基础设施并具备维护技能的公司更容易摊销这一选择。
当欧盟主权 BaaS 是正确的选择时
对于没有专门基础设施团队、需要向客户或 DPO 快速证明合规性的中小企业来说，欧盟主权 BaaS 是正确的选择。因此，她更愿意将工程时间投入到产品上，而不是 Postgres 修补上。对于优先考虑发布速度而不是堆栈的完全控制的团队来说，这也是相关的选择。
您依赖于供应商的可用性，而您的合同谈判空间取决于其规模和成熟度。在签署之前检查其合规清单，而不仅仅是其销售承诺。
Aurabase：同一 Postgres 核心下的两个模型
Aurabase 不会在一个方向上固定这一选择。该平台存在于欧盟主权管理的 BaaS 中，生产基础设施通过 Hetzner 在德国（纽伦堡、法尔肯斯坦）和芬兰（赫尔辛基）进行验证，由 Aurabase SAS（一家根据法国法律注册成立的公司）运营。它也存在于自托管中：存储库提供了通过 ./start.sh启动的本地 Kubernetes 集群（k3d），以及 Kubernetes 的完整 Helm 图表，所有这些都在 MIT 许可下。
双方均适用相同的 PostgreSQL 16 引擎、相同的 RLS 策略和相同的 SDK：从一种模型迁移到另一种模型不需要重写架构。为了将这种自托管模式与其他单二进制 Rust 原生后端（sh0.dev、TrailBase）进行比较，我们的文章Sovereign self-hosting：Aurabase 与 Rust 原生 BaaS 详细探讨了这个架构角度。这仍然集中在 GDPR 决定上。
决定前的快速清单
除了 GDPR 指南中的供应商验证清单之外，在选择之前还需要问自己四个操作问题。
| 01 | 您是否有一个值班人员能够在周末修补关键的 Postgres CVE？ |
|---|---|
| 02 | 您上次的备份恢复是否经过测试，而不是刚刚安排好的？ |
| 03 | 您能否为您自己使用的每个技术分包商制作最新的 DPA？ |
| 04 | DPO 或客户能否在一周内获得合规证明？ |
For the complete vendor verification checklist, including legal issues, see our GDPR compliance checklist for a BaaS. For the associated technical security posture, see Aurabase Security page.