Fly Postgres，由 Supabase 托管

合作与产品

• Supabase 将在 Fly.io 的基础设施上运行一项托管 Postgres 服务，类似于 Fly 现有的 Redis 合作。
• Fly 现有的 Postgres 是“自动化但不托管”的；新的选项则是明确的托管服务，由 Supabase 负责监控、健康检查和运维。
• 高可用特性正在测试中；时间安排和具体功能集尚未完全明确。

托管 vs 非托管 Postgres

• 托管：更接近 Heroku 风格的体验。你拿到一个连接字符串；由提供方负责扩容、健康检查、故障切换和值班响应。
• 目前的 Fly Postgres：提供编排工具和集群能力，但用户需要自己监控、配置规格并修复故障。
• 多位评论者表示：对于核心生产数据，他们会选择新的托管方案；Fly 自己的 Postgres 更适合副项目、实验或风险较低的服务。

可靠性、SLA 与存储模型

• 有人对 Fly 过去的正常运行时间以及“自己动手”式支持姿态提出担忧；也有人说可靠性已有提升，尤其是在迁移到 Machines 之后。
• 线程中有人要求正式 SLA，但没有得到回应。
• Fly 的 volumes 是主机本地 NVMe，不是 SAN/网络存储；持久性和复制必须在应用/数据库层处理。
• Fly 会定期备份 volumes，并可在内部将其迁移到其他主机，但 volumes 仍被视为不像 S3 那样、也并非天然“安全”。

连接处理与网络

• Supabase-on-Fly 的方案将使用 Supabase 自己的 Postgres 连接池和 PostgREST，而不是 Fly 的 HAProxy。
• 过去 Fly Postgres 上 HAProxy 超时的问题，促使人们对这一点感兴趣。
• 将 Supabase 放在 Fly 的网络内部，可以避免 Fly 应用与外部数据库之间因不稳定的出站 IP 和 IP 白名单而产生的问题。

定价与范围

• 早期迹象表明，定价将遵循 Supabase 现有方案，测试结束后可能会做一些更偏开发者友好的调整。
• 关于具体资源规格（CPU/RAM）、独立托管数据库定价，以及内部带宽计费，仍有疑问；回答不完整或不明确。

Supabase 平台与扩展

• Supabase 本质上“只是 Postgres”（目前运行在 AWS 上），其扩展特性类似 RDS，并被提及有一些大型生产用户。
• 逻辑复制受到支持，并被强调为相较某些其他托管 Postgres 提供商的一个差异点。
• 一些人觉得 Supabase 的分层定价和网络限制令人沮丧；另一些人则重视它的 Postgres 生态、开发体验和附加组件。

API、业务逻辑与 RLS

• Supabase 提供：
  • 直接的 Postgres 访问。
  • 自动生成的 REST（PostgREST）。
  • Edge/serverless functions。
• 多位评论者警告说，复杂用法配合 PostgREST 往往会把业务逻辑推入存储过程（PL/pgSQL 或 JS 扩展），这会显得笨拙且难以调试。
• 行级安全（Row-Level Security）因其表达能力受到赞赏，但也因以下问题受到批评：
  • 在复杂/聚合查询上的性能问题。
  • 调试和测试困难，尤其是策略涉及 join 时。
• 建议：简单场景很合适；复杂 ACL 需要大量 SQL/PL/pgSQL 专业知识，并且要仔细进行性能调优。

替代方案与更广泛的背景

• 有人认为，新项目可以考虑分布式 SQLite（例如 Turso）或 Cloudflare 风格的“edge + 分布式数据库”栈，而不是 Postgres。
• 反方观点：
  • Postgres 功能更丰富（例如 ltree 等扩展、逻辑复制、搜索工具）。
  • Cloudflare Workers 没有原生的 Postgres 等价方案；D1 和类似选项也有各自的取舍和成熟度问题。
• 还提到了其他生态：Crunchy Bridge、Neon、k3s + cloudnativepg、Tembo、ParadeDB；线程指出，大多数竞争性的托管 Postgres 产品历史上都没有暴露 WAL/逻辑复制，不过 Neon 最近已添加 CDC。