仅欧洲替代方案 Supabase.

Supabase is the open-source Firebase alternative: hosted Postgres + Auth + Storage + Edge Functions + Realtime with a polished developer experience. Supabase Inc. is a Delaware US corporation; the EU regions (Frankfurt, Ireland, London, Paris) run on AWS infrastructure under both Supabase and AWS US-jurisdictional control. The good news: Supabase is open-source. You can self-host the entire stack on EU infrastructure with full feature parity - that is the sovereign alternative we deploy for clients.

United States 仅限 EU 的替代技术栈 10 已梳理的服务
预约通话 先扫描您的域
供应商
Supabase
总部
San Francisco, CA
司法管辖区
United States
法律制度
CLOUD Act, FISA 702

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

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

驻留

数据物理存储在哪里?

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

次级处理者

您的数据路径中还有谁?

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

司法管辖区

哪些法律可以强制披露?

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

密钥托管

谁实际持有加密密钥?

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

失败 AWS · Azure · GCP · EU 区域

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

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

通过 Binadit 托管技术栈

四项全部通过。

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

为什么团队正在退出 Supabase

Supabase exits we have run come from one consistent trigger: a B2B SaaS that picked Supabase for its DX, grew to enterprise customers, and discovered that "Supabase Frankfurt on AWS Ireland" is two layers of US-jurisdictional processors that fail Schrems II analysis. The Supabase team itself has publicly discussed the data sovereignty constraints on their blog. Self-hosting Supabase on EU infrastructure preserves the full DX (the same supabase-js client works) while moving to full EU jurisdiction.

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

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

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. Days 1-5

    Self-hosted Supabase deployment

    Deploy self-hosted Supabase stack on Binadit (Docker Compose or Kubernetes). Configure auth providers, storage backend, Edge Functions runtime. Set up monitoring and backups.

  2. Days 6-14

    Database + auth migration

    Postgres dump+restore to self-hosted instance. User accounts migrated via auth provider data export. Storage buckets mirrored. Edge Functions redeployed.

  3. Weeks 2-3

    Application cutover

    Application config updated to point at self-hosted Supabase URL. Same supabase-js client, same RLS policies, same auth flows. Cutover with a verification window.

Self-hosted Supabase on a single small VM replaces Supabase Pro at $25 per project per month plus per-project usage. For multi-project workloads, savings compound: a typical Supabase team plan ($599/month) becomes €40-100/month in raw infrastructure plus the managed-partner fee if you don't want to operate it yourself. Plus full EU jurisdiction.

常见问题

查看所有常见问题

Is Supabase's EU region (Frankfurt, Ireland) sufficient for GDPR?
Residency yes, sovereignty no. Supabase Inc. is US-headquartered, and the Frankfurt/Ireland regions run on AWS - also US-jurisdictional. For Schrems II analyses, both layers are exposed.
Does self-hosted Supabase have full feature parity?
Yes for the core stack: Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. The supabase-js client works identically. The features that aren't in self-hosted: paid-tier features like team management UI and integrated logging dashboards (you build those with Loki + Grafana on EU infra).
How operationally complex is self-hosted Supabase?
For single-environment production, a single modest VM with Docker Compose is sufficient and operationally manageable for an experienced engineering team. For multi-environment or HA setups, Kubernetes with Helm chart is the production pattern; we operate this for clients.
Does the supabase-js client need code changes?
Just one: the URL points at your self-hosted instance instead of `*.supabase.co`. RLS policies, auth flows, storage URLs, realtime subscriptions - all unchanged.
What about managed Supabase EU equivalents?
There are emerging EU-headquartered offerings (Supascale, Supafast - both early-stage), but the production-ready answer is self-hosted Supabase managed by an EU partner. We deploy and operate this exact pattern.
How long does a Supabase exit take?
For a single-environment project (one Postgres, basic auth, a few buckets): 1-2 weeks elapsed. For multi-environment or large-data setups: 3-6 weeks. The migration is mechanically clean because everything is open-source upstream.

规划您的退出 Supabase.

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

预约通话 对比其他服务商