从 Supabase 迁移

如果你除了数据库之外，还用 Supabase 做认证、存储、边缘函数和实时，那么迁到 CapyDB 意味着替换四个产品而不是一个。这可能是对的决定——当应用已经被这种耦合拖住时通常就是——但那是一个项目，不是一个下午。

如果你主要把 Supabase 当作托管的 Postgres，其余只是顺带，那这就是一次直白的迁移，本页剩下的内容是写给你的。

• -你的 schema、数据、索引、约束、函数和触发器
• -扩展，通过按单元启用的目录
• -你的迁移脚本，无论由哪种工具生成
• -所有客户端库，因为连接字符串就是一条普通的 postgres:// URL

Supabase 的行级安全策略是针对它的 auth schema 和 JWT claim 辅助函数写的。这些东西在 Supabase 之外并不存在，所以直接导出再恢复，留给你的是一堆引用着不存在函数的策略。

CLI 会做转换。转换器是开源的，会把策略改写成基于原生 PostgreSQL 会话设置的形式，并把无法翻译的部分报告出来，而不是悄悄产出一份放得太宽的结果。

capydb migrate rls ./supabase --out capyrls

• -认证：改用专门的身份提供方，然后把同样的 claim 写进转换后策略所读取的会话设置里
• -存储：对象存储加签名 URL；codemod 会映射常见情形下的 bucket 语义，其余的报告出来
• -边缘函数：你的部署平台本来就在跑的东西——它们就是普通的 serverless 函数
• -实时：PostgreSQL 的逻辑复制和 LISTEN/NOTIFY 在单元里都可用
• -数据库本身：这才是真正意义上的整体搬迁部分

直接从你的 Supabase 连接字符串导入。导入器知道哪些平台 schema 不该跟着走并会过滤掉，于是你最终拿到的是自己的数据，而不是别人控制平面的一份副本。

capydb import \
  --project my-app \
  --source-url "$SUPABASE_DATABASE_URL" \
  --follow

• -用跟随模式导入，并在源库仍然存活时对着单元跑测试套件
• -应用转换后的策略，并用真实会话而非超级用户连接来验证
• -运行 capydb doctor，检查仍指向旧项目的环境变量
• -按环境替换连接字符串，盯着日志，然后停止跟随
• -把源库以只读方式留一周——花不了多少，却救过不少人

生产切换前请告诉我们。我们会审阅方案、在窗口期在线，并备好一条恢复路径。