仅欧洲替代方案 Supabase.

Supabase 是开源的 Firebase 替代方案：托管的 Postgres + Auth + Storage + Edge Functions + Realtime，具备完善的开发者体验。Supabase Inc. 是一家美国特拉华州公司；其 EU 区域（法兰克福、爱尔兰、伦敦、巴黎）运行在 AWS 基础设施上，同时受 Supabase 和 AWS 两方美国司法管辖权的控制。好消息是：Supabase 是开源的。您可以在 EU 基础设施上自建整套技术栈，功能完全对等，这正是我们为客户部署的主权替代方案。

美国仅限 EU 的替代技术栈 10 已梳理的服务

预约通话先扫描您的域

供应商: Supabase
总部: San Francisco, CA
司法管辖区: 美国
法律制度: CLOUD Act, FISA 702

"欧盟区域"不等于主权。四个问题决定一切。

数据驻留告诉你数据存放在哪里。主权则告诉你哪个法律体系可以强制访问。这四点的答案必须都成立 - 否则该技术栈就不具备主权性。

驻留

数据物理存储在哪里?

不只是笼统的“在云端” - 而是具体在哪个数据中心、哪个国家、受哪种司法管辖。

次级处理者

您的数据路径中还有谁?

每一个接触数据的供应商:CDN、邮件中继、错误追踪、分析管道。

司法管辖区

哪些法律可以强制披露?

总部位于美国的提供商受 FISA 702 和 CLOUD Act 管辖 - 即使数据存放在法兰克福也不例外。

密钥托管

谁实际持有加密密钥?

如果云服务商同时持有数据和密钥，无论签订何种 DPA，数据对其而言都是可读的。

失败 AWS · Azure · GCP · EU 区域

在司法管辖权和密钥托管上失败。

欧盟数据、美国母公司、默认路径中的美国次级处理者、供应商管理的密钥。

通过 Binadit 托管技术栈

四项全部通过。

托管在欧盟、由欧盟总部基础设施提供。默认路径中零美国次级处理者。客户持有或欧盟 KMS 密钥。在您的第 28 条 DPA 中按名称列出。

为什么团队正在退出 Supabase

我们所处理的 Supabase 迁出案例都源于一个一致的诱因：一家 B2B SaaS 因其开发体验选择了 Supabase，业务发展到企业客户阶段后，发现“AWS 爱尔兰上的 Supabase 法兰克福”实际上是两层美国司法管辖权的处理方，无法通过 Schrems II 分析。Supabase 团队自己也在其博客上公开讨论过数据主权方面的限制。在 EU 基础设施上自建 Supabase，可以保留完整的开发体验（同样的 supabase-js 客户端仍可使用），同时转向完全的 EU 司法管辖权。

Supabase 服务及其仅欧盟等效方案

迁移不是"换一个盒子"。下面的映射是我们为离开以下平台的客户运行的 Supabase 基于 Schrems II 的考量 - 完全适用欧盟司法管辖，数据链路中不涉及美国母公司。

Supabase 服务	我们改用什么	工程说明
Postgres (managed)	Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。	流式复制让我们能够以数秒的停机时间完成切换，而无需专门的维护窗口，且恢复流程会按计划定期测试，而不是想当然地假设可行。
Auth (GoTrue)	Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。	GoTrue 是开放 Supabase 技术栈的一部分；自托管可保留基于 JWT 的身份验证，支持社交登录、magic links 和 MFA。
Storage (S3-compatible)	Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。	Supabase Storage 是构建在兼容 S3 的存储之上的服务层，可与任何欧盟 S3 后端配合使用。
Edge Functions (Deno)	Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。	Edge Functions 本质上是 Deno 运行时；自托管的等效方案可以运行在任何 EU 容器平台上。
Realtime (Postgres CDC)	Binadit 托管云平台。PostgreSQL 逻辑复制到 websocket 层，或使用 NATS 进行扇出分发。	Realtime 是开源的；自行托管可保留基于 WebSocket 的发布/订阅机制。
Vector embeddings (pgvector)	Binadit 托管云平台。PostgreSQL 上的 pgvector，或对于更大规模的嵌入向量集使用 Qdrant。	对于专用的向量数据工作负载，Qdrant Cloud EU 是一个默认符合主权要求的替代方案。
Studio (admin UI)	Binadit DevOps 与支持服务。使用 pgAdmin 或 Metabase 进行数据访问，配合 Grafana 提供运维视图。	Studio 是自托管发行版的一部分。
Database backups	Binadit 托管云平台。使用 restic 和 pgBackRest 备份数据，Velero 备份 Kubernetes 状态，存储至隔离的欧盟存储。	使用欧盟对象存储后端的 WAL-G 是生产级的标准模式。
API (PostgREST)	Binadit 托管云平台。Traefik 或 Kong，在边缘层实现限流与 OIDC 认证。	PostgREST 是开源的；自行托管可保留其 REST API 生成能力。
CLI / Migrations	Binadit DevOps 与支持服务。kubectl、Terraform 和 GitLab CI，在有帮助的地方使用项目专属封装工具。	Supabase CLI 支持通过 `--db-url` 参数指向自托管实例。

Postgres (managed)

我们改用什么: Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。
工程说明: 流式复制让我们能够以数秒的停机时间完成切换，而无需专门的维护窗口，且恢复流程会按计划定期测试，而不是想当然地假设可行。

Auth (GoTrue)

我们改用什么: Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。
工程说明: GoTrue 是开放 Supabase 技术栈的一部分；自托管可保留基于 JWT 的身份验证，支持社交登录、magic links 和 MFA。

Storage (S3-compatible)

我们改用什么: Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。
工程说明: Supabase Storage 是构建在兼容 S3 的存储之上的服务层，可与任何欧盟 S3 后端配合使用。

Edge Functions (Deno)

我们改用什么: Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。
工程说明: Edge Functions 本质上是 Deno 运行时；自托管的等效方案可以运行在任何 EU 容器平台上。

Realtime (Postgres CDC)

我们改用什么: Binadit 托管云平台。PostgreSQL 逻辑复制到 websocket 层，或使用 NATS 进行扇出分发。
工程说明: Realtime 是开源的；自行托管可保留基于 WebSocket 的发布/订阅机制。

Vector embeddings (pgvector)

我们改用什么: Binadit 托管云平台。PostgreSQL 上的 pgvector，或对于更大规模的嵌入向量集使用 Qdrant。
工程说明: 对于专用的向量数据工作负载，Qdrant Cloud EU 是一个默认符合主权要求的替代方案。

Studio (admin UI)

我们改用什么: Binadit DevOps 与支持服务。使用 pgAdmin 或 Metabase 进行数据访问，配合 Grafana 提供运维视图。
工程说明: Studio 是自托管发行版的一部分。

Database backups

我们改用什么: Binadit 托管云平台。使用 restic 和 pgBackRest 备份数据，Velero 备份 Kubernetes 状态，存储至隔离的欧盟存储。
工程说明: 使用欧盟对象存储后端的 WAL-G 是生产级的标准模式。

API (PostgREST)

我们改用什么: Binadit 托管云平台。Traefik 或 Kong，在边缘层实现限流与 OIDC 认证。
工程说明: PostgREST 是开源的；自行托管可保留其 REST API 生成能力。

CLI / Migrations

我们改用什么: Binadit DevOps 与支持服务。kubectl、Terraform 和 GitLab CI，在有帮助的地方使用项目专属封装工具。
工程说明: Supabase CLI 支持通过 `--db-url` 参数指向自托管实例。

我们如何迁移离开 Supabase

典型的中端市场迁移分为三个阶段进行。以下数据假设工程团队规模为 6-10 人，应用程序技术栈复杂度中等。

第 1-5 天

自托管 Supabase 部署

在 Binadit 上部署自托管 Supabase 技术栈（Docker Compose 或 Kubernetes）。配置身份验证提供商、存储后端、Edge Functions 运行时。设置监控和备份。
第 6-14 天

数据库 + 身份验证迁移

通过dump+restore将Postgres迁移至自托管实例。用户账户通过auth提供商的数据导出功能迁移。存储桶进行镜像同步。Edge Functions重新部署。
第 2-3 周

应用切换

应用配置已更新，指向自托管的 Supabase URL。使用相同的 supabase-js 客户端、相同的 RLS 策略、相同的认证流程。切换过程附带验证窗口期。

在单台小型虚拟机上自托管 Supabase，可替代每项目每月 25 美元起的 Supabase Pro 及其按项目用量计费。对于多项目工作负载，节省效果会成倍增加：典型的 Supabase 团队套餐（每月 599 美元）可降至每月 40-100 欧元的基础设施成本，若不想自行运维，再加上托管服务费即可。而且完全符合欧盟司法管辖要求。

常见问题

查看所有常见问题

Supabase的EU区域（法兰克福、爱尔兰）对GDPR来说足够吗？

数据驻留达标，但主权不达标。Supabase Inc. 总部位于美国，其法兰克福/爱尔兰区域运行在 AWS 上，同样受美国司法管辖。从 Schrems II 分析角度看，两层均存在风险敞口。

自托管 Supabase 是否具备完整的功能对等性？

对于核心技术栈，Postgres、Auth（GoTrue）、Storage、Edge Functions、Realtime、Studio、PostgREST，答案是肯定的。supabase-js客户端的表现完全一致。自托管版本不具备的功能包括：付费层级功能，如团队管理界面和集成日志仪表盘（您需要在欧盟基础设施上用Loki + Grafana自行构建这些功能）。

自托管 Supabase 的运维复杂度有多高?

对于单一环境的生产部署，使用 Docker Compose 搭配一台配置适中的 VM 即已足够，对于有经验的工程团队来说也便于运维管理。对于多环境或高可用（HA）部署，采用 Helm chart 的 Kubernetes 是生产环境的标准方案；我们为客户运营此类架构。

supabase-js 客户端需要修改代码吗？

只有一处：URL 指向你的 self-hosted 实例，而不是 `*.supabase.co`。RLS 策略、auth 流程、storage URL、realtime 订阅，全部保持不变。

托管 Supabase 的欧盟等效方案怎么样？

目前已有一些新兴的欧盟总部产品（Supascale、Supafast，均处于早期阶段），但可用于生产环境的方案是由欧盟合作伙伴托管运维的自托管 Supabase。我们部署并运营的正是这种模式。

Supabase 迁移退出需要多长时间?

对于单一环境项目(一个 Postgres、基础认证、少量 bucket):耗时1-2周。对于多环境或大数据量场景:3-6周。由于所有组件在上游都是开源的,迁移过程干净利落。

规划您的退出 Supabase.

30 分钟范围确定通话。我们将您的技术栈映射到仅欧盟替代方案,估算迁移工作量,并告诉您这是否是正确的选择。

预约通话对比其他服务商