Postgres en Fly administrado por Supabase
(supabase.com)- La colaboración entre Supabase y Fly.io para ofrecer Postgres administrado fue un intento de permitir el uso de las funciones de base de datos de Supabase sobre la infraestructura de Fly, pero actualmente está descontinuada
- El servicio buscaba desplegar Postgres en un entorno de edge computing que se ejecuta en más de 37 ubicaciones de Fly.io, para acercar más las aplicaciones de Fly y la base de datos
- El alcance funcional incluía más de 40 extensiones, pgvector, Supavisor, respaldos diarios, recuperación a un punto en el tiempo, branching, observabilidad, migraciones, dashboard y APIs REST/GraphQL generadas automáticamente
- El despliegue inicial se realizaba de forma gradual, y aún quedaban trabajos de integración entre compañías como facturación, transferencia de soporte y capacitación interna, además de correcciones de bugs reportados por testers iniciales
- Mientras que el Postgres existente de Fly era no administrado y dejaba la responsabilidad operativa en manos del usuario, Fly Postgres era un servicio administrado en el que Supabase se encargaba del escalado, respaldos, replicación y actualizaciones
Estado del lanzamiento y alcance del servicio
- Fly Postgres está actualmente descontinuado; se puede encontrar más información en el aviso de descontinuación
- Supabase y Fly.io lanzaron Fly Postgres como un servicio de Postgres administrado que funciona sobre la infraestructura de Fly
- Las bases de datos se ejecutan en la plataforma de edge computing de Fly.io y podían iniciarse eligiendo entre más de 37 ubicaciones de Fly.io
- Las aplicaciones intensivas en datos desplegadas en Fly podían esperar menor latencia al mantener la base de datos dentro de la misma infraestructura
Funciones de Postgres administrado por Supabase
- Fly Postgres ofrecía en el entorno de Fly las funciones principales que se esperan de una base de datos administrada por Supabase
- Más de 40 extensiones de Supabase Postgres
- Soporte para cargas de trabajo Vector/AI basadas en pgvector
- Supavisor, el pooler de conexiones Postgres de Supabase
- Respaldos diarios y recuperación a un punto en el tiempo
- Branching, observabilidad y migraciones
- Dashboard para administrar la base de datos
- Data API generada automáticamente
- API REST que usa PostgREST
- API GraphQL que usa pg_graphql
Rollout gradual y pruebas iniciales
- El lanzamiento se realizó mediante un rollout gradual
- La integración entre compañías incluía trabajos como facturación, transferencia de soporte y capacitación del personal de Supabase
- Se estaba validando con algunos testers iniciales y aún quedaban bugs por corregir
- Quienes quisieran participar en las pruebas podían registrarse en la waitlist
- Se planeaba aceptar más testers al mes siguiente y compartir más fechas de lanzamiento después de tener confianza en la seguridad de los datos
Diferencia entre Postgres administrado y no administrado
- La oferta existente de Postgres de Fly era no administrada
- El usuario debía encargarse directamente del escalado, los respaldos a un punto en el tiempo, la replicación, las actualizaciones de versiones mayores, etc.
- Con el Postgres administrado de Fly operado por Supabase, los usuarios podían enfocarse más en crear sus aplicaciones
- El servicio administrado se creó con la Fly extension API
- La misma API también se usa para Fly Redis
- Los testers podían crear bases de datos Postgres con el comando
fly extensionsfly extensions supabase create
- Cuando el servicio se estabilizara, se esperaba reemplazarlo por el namespace
postgresfly postgres create
Implementación basada en Fly Machines
- Fly Postgres se construyó sobre Fly machines
- Machines son VM Firecracker ligeras, y la Machines API permite controlar con detalle el ciclo de vida de las aplicaciones
- Machines pueden detenerse cuando están inactivas y reanudarse en unos segundos cuando llega una nueva solicitud
- Supabase creó un wrapper de TypeScript llamado fly-admin para simplificar la interacción con la API de Fly
- Como Supabase agrupa varios servicios adicionales con Postgres, preparó una única imagen Docker que se puede pasar a la Fly Machines API
- El proceso de build existente crea AMI para AWS con Packer, y se reutilizó parte de ese pipeline para construir la All In One Image
- La All In One Image incluye en un solo contenedor Docker todos los servicios necesarios para ejecutar un proyecto de Supabase
Transición a multicloud
- Con este lanzamiento, Supabase se convirtió oficialmente en multicloud
- Supabase evitó deliberadamente los servicios administrados de AWS para simplificar la transición a multicloud
- La transición no es simple porque los proveedores cloud tienen primitivas básicas muy distintas
- Fly Machines ofrece una forma de detener las VM que no se usan y reanudarlas de manera transparente en segundos
- Se simplifica el proceso de pausar bases de datos inactivas
- AWS no tiene una primitiva para lograr esto directamente
- En cambio, Fly carece de algunas primitivas que sí ofrece AWS, por lo que se necesitan soluciones alternativas
- Fly Machines no tiene almacenamiento conectado por red
- Supabase trata los datos de Fly volumes como datos temporales
- Realiza respaldos físicos con WAL-G para todos los proyectos que se ejecutan en Fly
- Los cambios de la base de datos se transmiten continuamente a S3
- Si se daña el host o el volumen, el proyecto se restaura en un nuevo host de Fly usando los datos más recientes de S3
Observabilidad operativa y despliegue de imágenes
- En AWS, Supabase recibe AWS Health events para detectar problemas en los hosts
- En Fly, envía los logs de Machine a Logflare mediante fly-log-shipper
- Supabase publica la All In One image no solo en el registro de contenedores de AWS, sino también en el registro Docker de Fly
- Publicar en el registro Docker de Fly mejoró la confiabilidad y el rendimiento al iniciar proyectos en Fly
Extensiones de Fly e integración de autenticación
- Fly proporciona una Extensions API para extender la plataforma
- Supabase agregó algunas rutas a la API para provisionar usuarios y proyectos
- Los usuarios de Fly pueden acceder al dashboard de Supabase con sus credenciales de Fly existentes
- La API de Supabase inicia un flujo OAuth con Fly para autenticar al usuario
- El equipo de Supabase Auth creó un Fly OAuth provider para facilitar la integración con la API
Tareas pendientes
- Supabase seguía trabajando con el equipo de Fly en algunos desafíos operativos
-
Soporte para restricciones de red
- La función de restricciones de red requiere que el contenedor reciba la IP correcta del cliente que se conecta
- En la configuración actual, el contenedor ve la IP del proxy de Fly en lugar de la IP del cliente
- La conexión pasa por el proxy de Fly, que expone Proxy protocol
- Postgres no puede usar esta información directamente, y Supabase está evaluando hacer que Supavisor reconozca proxy-protocol
-
Respaldos internos en Fly
- Fly todavía no ofrece almacenamiento Blob administrado, por lo que los respaldos de los proyectos de Fly se realizan en AWS S3
- Este enfoque genera costos de ancho de banda entre nubes
- Fly está trabajando en Blob Storage
Cómo empezar y precios
- La solicitud para la preview podía realizarse en el preview form
- Una vez que la organización fuera agregada a la lista de permitidos, se podía empezar con el Quickstart de la documentación
- Las organizaciones de Fly podían recibir un proyecto gratuito
- Los detalles de facturación todavía estaban en desarrollo, pero no se esperaba que los precios cambiaran mucho respecto de los precios actuales de Supabase
1 comentarios
Opiniones en Hacker News
Soy el CEO de Supabase. El Postgres actual de Fly es no administrado, así que estamos trabajando con Fly para operar un servicio administrado.
Es el mismo modelo que usamos con el equipo de Upstash en Fly Redis: https://fly.io/docs/reference/redis/
Todavía estamos desplegando funciones de alta disponibilidad con testers y no hay una fecha definida, pero avanzaremos con el equipo de Fly lo más rápido posible.
No he visto muchos casos en los que una empresa externa entre a colaborar para administrar una versión hospedada de los servicios no hospedados de otra compañía.
Hace tiempo revisé Supabase y me confundió cómo se crea la API REST básica.
Me parece bien que al crear tablas genere automáticamente una API para interactuar con ellas, pero entonces no sé dónde debería quedar la lógica de negocio.
También vi Edge Functions, pero los ejemplos parecían más orientados a procesamiento de tareas, así que no me quedó claro si era para usarlas con ese fin; sentí que me estaba perdiendo algo simple.
La API REST es bastante cómoda para agregaciones de datos como joins, pero en cuanto necesitas cosas como transacciones empieza a quedarse corta.
La seguridad a nivel de fila (RLS) para control de acceso basado en roles también fue engorrosa, y la experiencia de desarrollo dejó que desear.
Si los requisitos de la DB son simples, la API REST es muy cómoda, pero si planeas algo complejo, conviene aprender PL/pgSQL o usar una conexión normal a la DB.
Para la mayoría, la opción 1 basta; la 2 y la 3 son más bien herramientas adicionales para cuando se necesitan.
En muchos casos de uso, la lógica puede ponerse en procedimientos almacenados SQL, y PostgreSQL también permite procedimientos almacenados en JS o Python.
Dicho eso, para el código de lógica la experiencia de desarrollo suele ser mejor desplegándolo como contenedores o funciones con CI/CD normal, y según el compromiso de costos se usan mucho ambas opciones.
Supabase recomienda funciones serverless de Deno, pero para un proyecto web creo que la mayoría preferiría desplegar funciones Node en Cloudflare.
Al final, parece que el cliente objetivo es quien quiere poner el 99% de la lógica en el frontend JS y que el backend solo se encargue de CRUD y autenticación.
Para esa parte creamos un sistema de eventos basado en el WAL de Postgres y lo tratamos como un sistema de callbacks.
También hicimos una pequeña librería para Elixir que originalmente empezó como un fork de Supabase Realtime: https://github.com/cpursley/walex
Recientemente agregamos una función para configurar WalEx de modo que entregue eventos a webhooks o a EventRelay, sin necesidad de saber Elixir.
Como usamos Next.js, muchas llamadas a la DB están dentro de funciones serverless de Next.
Aun así, pensamos revisar si conviene mover parte de la lógica a funciones de Supabase para mantenerla lo más cerca posible de la DB, aunque todavía no quería migrar a Deno.
Cuando accedes a Supabase desde el servidor, puedes usar las funciones de PostgREST que usa el cliente de Supabase, o acceder directamente a Postgres con una librería común como
pg.Me entusiasma pasarme a esto. He estado construyendo Booklet sobre Fly.io y Fly Postgres, estructurando la app de forma distribuida: https://www.contraption.co/essays/booklet-architecture/
El mayor problema fue la configuración de Fly Postgres. En particular, Fly pone HAProxy delante de Postgres y aplica un límite de conexión de 30 minutos, lo que corta las conexiones constantemente: https://community.fly.io/t/postgresql-connection-issues-have...
Debería ser un problema manejable, pero el comportamiento de cierre de conexiones no coincide con la documentación en aspectos extraños, así que sigue siendo inestable.
Me pregunto si el nuevo Postgres también tendrá el mismo HAProxy al frente.
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
Hoy vi esto en la documentación de Fly y pensé que quizá se me había pasado en HN, pero resulta que era nuevo.
Lo segundo que pensé fue que se siente raro tener Postgres by Fly y Postgres by Supabase juntos en la barra lateral.
Tampoco hay una comparación clara, así que si despliegas una app en Fly y necesitas Postgres, no queda claro cuál deberías usar.
Personalmente, si necesito un DBMS en Fly probablemente usaría SQLite distribuido con LiteFS, y si necesito Postgres, veo la diferencia entre Fly y Supabase básicamente como no administrado vs. administrado.
Muy bueno. Nunca me gustó mucho la configuración de restricciones de red de Supabase: https://supabase.com/docs/guides/platform/network-restrictio...
Recuerdo que, cuando lo vi antes, había algún problema raro al exponer la IP de una app de Fly a Supabase y bloquear Supabase a esa IP
Que Supabase realmente entre dentro de la red de Fly es excelente
También aparece en la documentación de networking de Fly.io
He oído que Supabase tiene problemas de escalabilidad cuando se va más allá del prototipo; me pregunto si alguien con experiencia en producción puede comentar
¿A qué problemas te refieres específicamente?
Soy Joshua, de Fly.io. Si tienen preguntas sobre esta integración, las respondo
Lo uso para algunos proyectos personales, pero todavía no para proyectos grandes
Lo siguiente que quisiera es almacenamiento Blob, porque básicamente prefiero usar servicios administrados para las cosas con estado, así que me alegra que también estén avanzando en eso
Me pregunto si hay detalles sobre el precio de la nueva oferta de Postgres
Actualmente corremos una BD grande en Fly y estamos buscando PostgreSQL administrado, así que esta noticia nos alegra mucho
Somos un equipo completamente de Elixir, así que el timing no podría ser mejor
“Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
Nunca he usado AWS y tampoco conozco bien el almacenamiento conectado por red, así que me pregunto exactamente en qué se diferencian los volúmenes de Fly del almacenamiento conectado por red de otros proveedores
Creo que cuando creabas un volumen de Fly podías moverlo a otro servidor en la misma región; entonces, ¿técnicamente no es almacenamiento conectado por red?
Internamente podemos mover un volumen de un host físico a otro, y la forma en que lo hacemos es bastante interesante, pero todavía no la hemos expuesto mucho públicamente
Este año vamos a hacerla más visible
Fly Volumes se respalda periódicamente en almacenamiento de bloques fuera de la red, y pronto también habrá más anuncios relacionados con eso
Lo básico que hay que entender es que Fly Volumes no es almacenamiento SAN, ni tampoco un almacenamiento inherentemente confiable como S3
Dentro de Fly Machines se ve como un simple sistema de archivos ext4, y si necesitas confiabilidad, durabilidad o replicación, debes proporcionarlas en la capa de la aplicación
Fly Postgres funciona como un clúster de réplicas de lectura, y si hace falta cualquiera de las réplicas puede asumir el rol de líder de escritura, así que ese enfoque tiene sentido
Por eso también mostramos una gran advertencia roja en la consola cuando intentas crear un clúster de Postgres de un solo nodo
En los próximos trimestres probablemente lanzaremos nuevas opciones dentro del espectro de confiabilidad y rendimiento, pero no creo que terminemos operando directamente unidades SAN que solo expongan dispositivos de bloque al estilo iSCSI
De verdad detesto los modelos de precios de estas dos empresas
En un extremo está Supabase, con una estructura de planes por niveles tipo plataforma para desarrolladores como Vercel, que hace que pagues más de lo que realmente usas
En el otro extremo está Fly, con precios demasiado granulares por segundo, por memoria y por CPU, como Lambda, donde probablemente termines pagando demasiado poco y sufriendo degradación de rendimiento
Existiendo cosas como Cloudflare Workers, no entiendo bien por qué elegirías cualquiera de las dos. ¿Por qué todavía querer preocuparte por escalar?
Tampoco parece probable que Cloudflare ofrezca un Postgres real. La filosofía de Cloudflare apunta a que todo lo que despliegas se distribuya por todo el mundo, mientras que una base de datos relacional obliga a tener un único servidor como fuente de verdad
Claro, me encantaría que se demostrara que estoy equivocado
Los precios mensuales de Fly son bastante intuitivos y no se parecen en nada a Lambda. De hecho, entre los dos, el modelo de precios de Cloudflare Workers es el que se parece más a Lambda