Fly Postgres, gestionado por Supabase

Artículo original ↗ Discusión en Hacker News ↗

Fly.io se asocia con Supabase para ofrecer un servicio de PostgreSQL totalmente gestionado sobre la infraestructura de Fly, cubriendo una carencia de larga data para equipos que querían la plataforma distribuida de apps de Fly pero dependían de bases de datos gestionadas para obtener fiabilidad. Los comentaristas comparan la oferta actual de Fly, “automatizada pero no gestionada”, con el enfoque gestionado al estilo Heroku de Supabase, con la fiabilidad, HA, supervisión y escalado como preocupaciones centrales. El hilo también explora filosofías de precios, alternativas como SQLite distribuido y otros proveedores de Postgres, y cuestiones arquitectónicas como la durabilidad del almacenamiento, los controles de salida de red y cuánto negocio conviene mover a Postgres mediante herramientas como PostgREST y la seguridad a nivel de fila.

Asociación y oferta

  • Supabase ejecutará un servicio de Postgres gestionado sobre la infraestructura de Fly.io, de forma similar a la asociación existente de Fly con Redis.
  • El Postgres actual de Fly es “automatizado pero no gestionado”; la nueva opción será explícitamente gestionada, con Supabase encargándose de la supervisión, la salud del servicio y las operaciones.
  • Las funciones de alta disponibilidad están en pruebas; el momento y el conjunto exacto de funciones no están completamente especificados.

Postgres gestionado vs. no gestionado

  • Gestionado: una experiencia más cercana a Heroku. Recibes una cadena de conexión; el proveedor se encarga del escalado, las comprobaciones de salud, el failover y la respuesta de guardia.
  • El Postgres de Fly hoy: se ofrecen herramientas de orquestación y clustering, pero se espera que los usuarios supervisen, dimensionen y remedien los fallos por su cuenta.
  • Varios comentaristas dicen: para datos críticos de producción, elegirían la nueva oferta gestionada; el propio Postgres de Fly encaja mejor para proyectos secundarios, experimentos o servicios de menor importancia.

Fiabilidad, SLA y modelo de almacenamiento

  • Surgen preocupaciones sobre el historial de disponibilidad de Fly y su postura de soporte de “hágalo usted mismo”; otros dicen que la fiabilidad ha mejorado, especialmente tras el paso a Machines.
  • Una solicitud de un SLA formal queda sin respuesta en el hilo.
  • Los volúmenes de Fly son NVMe local del host, no almacenamiento SAN/de red; la durabilidad y la replicación deben gestionarse en la capa de aplicación/base de datos.
  • Fly realiza copias de seguridad periódicas de los volúmenes y puede migrarlos internamente entre hosts, pero los volúmenes siguen tratándose como no similares a S3 y no inherentemente “seguros”.

Gestión de conexiones y red

  • La configuración de Supabase en Fly usará el propio pooler de conexiones de Postgres de Supabase y PostgREST en lugar de HAProxy de Fly.
  • Problemas pasados con timeouts de HAProxy en Fly Postgres motivaron el interés por esto.
  • Tener Supabase dentro de la red de Fly evita problemas con IPs salientes inestables y con el allowlisting de IPs entre apps de Fly y bases de datos externas.

Precios y alcance

  • La indicación inicial es que los precios seguirán los planes actuales de Supabase, posiblemente con ajustes favorables para desarrolladores después de las pruebas.
  • Quedan preguntas sobre las especificaciones precisas de recursos (CPU/RAM), el precio de una base de datos gestionada independiente y el cobro del ancho de banda interno; las respuestas son incompletas o poco claras.

Plataforma Supabase y escalado

  • Supabase es “solo Postgres” (actualmente en AWS) con características de escalado similares a RDS y algunos usuarios de producción a gran escala citados.
  • Se admite la replicación lógica y se destaca como un diferenciador frente a algunos otros proveedores de Postgres gestionado.
  • A algunos les frustran los precios escalonados y las restricciones de red de Supabase; otros valoran su ecosistema de Postgres, DX y complementos.

APIs, lógica de negocio y RLS

  • Supabase expone:
    • Acceso directo a Postgres.
    • REST autogenerado (PostgREST).
    • Funciones edge/sin servidor.
  • Varios comentaristas advierten que el uso complejo con PostgREST tiende a empujar la lógica de negocio hacia procedimientos almacenados (PL/pgSQL o extensiones JS), lo que puede ser torpe y difícil de depurar.
  • Row-Level Security es elogiado por su expresividad, pero criticado por:
    • Problemas de rendimiento en consultas complejas/de agregación.
    • Depuración y pruebas difíciles, especialmente cuando las políticas implican joins.
  • Orientación: bien para casos simples; los ACL complejos requieren bastante experiencia en SQL/PL/pgSQL y un ajuste cuidadoso del rendimiento.

Alternativas y contexto más amplio

  • Algunos sostienen que los nuevos proyectos podrían considerar SQLite distribuido (por ejemplo, Turso) o stacks al estilo Cloudflare de “edge + base de datos distribuida” en lugar de Postgres.
  • Contrapuntos:
    • Postgres tiene funciones más ricas (por ejemplo, extensiones como ltree, replicación lógica, herramientas de búsqueda).
    • Cloudflare Workers no tiene un equivalente nativo de Postgres; D1 y opciones similares tienen sus propios compromisos y dudas de madurez.
  • Otros ecosistemas mencionados: Crunchy Bridge, Neon, k3s + cloudnativepg, Tembo, ParadeDB; el hilo señala que históricamente la mayoría de las ofertas competidoras de Postgres gestionado no exponían WAL/replicación lógica, aunque Neon recientemente ha añadido CDC.