Fly Postgres, Managed by Supabase

Original Article ↗ Hacker News Discussion ↗

Fly.io is partnering with Supabase to offer a fully managed PostgreSQL service on Fly’s infrastructure, addressing a long-standing gap for teams that wanted Fly’s distributed app platform but relied on managed databases for reliability. Commenters weigh the trade-offs between Fly’s existing “automated but unmanaged” Postgres and Supabase’s Heroku-style managed approach, with reliability, HA, monitoring, and scaling as central concerns. The thread also explores pricing philosophies, alternatives like distributed SQLite and other Postgres providers, and architectural issues such as storage durability, network egress controls, and how much business logic to push into Postgres via tools like PostgREST and row-level security.

Partnership & Offering

  • Supabase will run a managed Postgres service on Fly.io’s infrastructure, similar to Fly’s existing Redis partnership.
  • Fly’s existing Postgres is “automated but unmanaged”; the new option is explicitly managed, with Supabase handling monitoring, health, and operations.
  • High-availability features are in testing; timing and exact feature set are not fully specified.

Managed vs Unmanaged Postgres

  • Managed: closer to Heroku-style experience. You get a connection string; provider handles scaling, health checks, failover, and on‑call response.
  • Fly Postgres today: orchestration tools and clustering provided, but users are expected to monitor, size, and remediate failures themselves.
  • Several commenters say: for core production data, they’d choose the new managed offering; Fly’s own Postgres suits side projects, experiments, or lower‑stakes services.

Reliability, SLA, and Storage Model

  • Concerns raised about Fly’s historical uptime and “do it yourself” support posture; others say reliability has improved, especially after moving to Machines.
  • A request for a formal SLA goes unanswered in the thread.
  • Fly volumes are host‑local NVMe, not SAN/network storage; durability and replication must be handled at the application/database layer.
  • Fly periodically backs up volumes and can migrate them between hosts internally, but volumes are still treated as non‑S3‑like and not inherently “safe.”

Connection Handling & Networking

  • The Supabase‑on‑Fly setup will use Supabase’s own Postgres connection pooler and PostgREST rather than Fly’s HAProxy.
  • Past issues with HAProxy timeouts on Fly Postgres motivated interest in this.
  • Having Supabase inside Fly’s network avoids problems with unstable outbound IPs and IP allowlisting between Fly apps and external databases.

Pricing & Scope

  • Early indication is that pricing will follow Supabase’s current plans, possibly with developer‑friendly adjustments post‑testing.
  • Questions remain about precise resource specs (CPU/RAM), standalone managed‑DB pricing, and internal bandwidth charging; answers are incomplete or unclear.

Supabase Platform & Scaling

  • Supabase is “just Postgres” (currently on AWS) with similar scaling characteristics to RDS and some large production users cited.
  • Logical replication is supported and highlighted as a differentiator vs some other managed Postgres providers.
  • Some find Supabase’s tiered pricing and network restrictions frustrating; others value its Postgres ecosystem, DX, and add‑ons.

APIs, Business Logic & RLS

  • Supabase exposes:
    • Direct Postgres access.
    • Auto‑generated REST (PostgREST).
    • Edge/serverless functions.
  • Multiple commenters warn that complex use with PostgREST tends to push business logic into stored procedures (PL/pgSQL or JS extensions), which can be clumsy and hard to debug.
  • Row‑Level Security is praised for expressiveness but criticized for:
    • Performance issues on complex/aggregate queries.
    • Difficult debugging and testing, especially when policies involve joins.
  • Guidance: fine for simple cases; complex ACLs require significant SQL/PL/pgSQL expertise and careful performance tuning.

Alternatives & Broader Context

  • Some argue new projects might consider distributed SQLite (e.g., Turso) or Cloudflare‑style “edge + distributed DB” stacks instead of Postgres.
  • Counterpoints:
    • Postgres has richer features (e.g., extensions like ltree, logical replication, search tooling).
    • Cloudflare Workers lack a native Postgres equivalent; D1 and similar options have their own trade‑offs and maturity concerns.
  • Other ecosystems mentioned: Crunchy Bridge, Neon, k3s + cloudnativepg, Tembo, ParadeDB; thread notes that most competing managed Postgres offerings historically did not expose WAL/logical replication, though Neon has recently added CDC.