Fly Postgres géré par Supabase
(supabase.com)- La collaboration entre Supabase et Fly.io autour d’un Postgres managé visait à rendre disponibles les fonctionnalités de base de données Supabase sur l’infrastructure de Fly, mais elle est désormais abandonnée
- Le service avait pour objectif de déployer Postgres dans un environnement d’edge computing exécuté sur plus de 37 emplacements de Fly.io, afin de rapprocher les applications Fly et les bases de données
- Le périmètre fonctionnel incluait plus de 40 extensions, pgvector, Supavisor, des sauvegardes quotidiennes, la restauration à un instant donné, le branching, l’observabilité, les migrations, un tableau de bord, ainsi que des API REST et GraphQL générées automatiquement
- Le déploiement initial devait se faire progressivement, avec encore des travaux d’intégration entre entreprises à finaliser, comme la facturation, le transfert du support et la formation interne, ainsi que la correction de bugs remontés par les premiers testeurs
- Alors que l’offre Postgres existante de Fly était non managée et laissait la responsabilité opérationnelle à l’utilisateur, Fly Postgres était un service managé dans lequel Supabase prenait en charge le scaling, les sauvegardes, la réplication et les mises à niveau
État du lancement et périmètre du service
- Fly Postgres est désormais abandonné ; plus de détails sont disponibles dans l’annonce d’abandon
- Supabase et Fly.io ont lancé Fly Postgres comme service Postgres managé fonctionnant sur l’infrastructure de Fly
- Les bases de données s’exécutaient sur la plateforme d’edge computing de Fly.io et pouvaient être démarrées dans l’un des plus de 37 emplacements de Fly.io
- Les applications à forte intensité de données déployées sur Fly pouvaient espérer une latence plus faible en plaçant la base de données dans la même infrastructure
Fonctionnalités de Postgres managé par Supabase
- Fly Postgres apportait à l’environnement Fly les principales fonctionnalités attendues d’une base de données managée Supabase
- Plus de 40 extensions de Supabase Postgres
- Prise en charge des workloads Vector/IA basés sur pgvector
- Supavisor, le pooler de connexions Postgres de Supabase
- Sauvegardes quotidiennes et restauration à un instant donné
- Branching, observabilité, migrations
- Tableau de bord pour l’administration de la base de données
- Data API générée automatiquement
- API REST utilisant PostgREST
- API GraphQL utilisant pg_graphql
Déploiement progressif et premiers tests
- Le lancement s’est fait sous forme de déploiement progressif
- L’intégration entre les entreprises comprenait des tâches comme la facturation, le transfert du support et la formation des employés de Supabase
- Le service était en cours de validation avec quelques premiers testeurs, et des bugs restaient à corriger
- Les personnes souhaitant participer au test pouvaient s’inscrire sur la waitlist
- Il était prévu d’accueillir davantage de testeurs le mois suivant et de partager un calendrier de lancement supplémentaire une fois la sécurité des données confirmée
Différences entre Postgres managé et non managé
- L’offre Postgres existante de Fly était non managée
- Les utilisateurs devaient gérer eux-mêmes le scaling, les sauvegardes à un instant donné, la réplication, les mises à niveau majeures, etc.
- Avec le Postgres managé de Fly opéré par Supabase, les utilisateurs pouvaient se concentrer davantage sur la construction de leurs applications
- Le service managé était créé avec la Fly extension API
- La même API est utilisée pour Fly Redis
- Les testeurs pouvaient créer une base de données Postgres avec la commande
fly extensionsfly extensions supabase create
- Une fois le service stabilisé, il devait être remplacé par le namespace
postgresfly postgres create
Implémentation basée sur Fly Machines
- Fly Postgres était construit sur Fly machines
- Les Machines sont de légères VM Firecracker, et l’API Machines permet un contrôle fin du cycle de vie des applications
- Les Machines peuvent être arrêtées en cas d’inactivité et relancées en quelques secondes lorsqu’une nouvelle requête arrive
- Supabase a créé un wrapper TypeScript appelé fly-admin afin de simplifier les interactions avec l’API Fly
- Comme Supabase regroupe plusieurs services supplémentaires avec Postgres, l’équipe a préparé une image Docker unique pouvant être transmise à l’API Fly Machines
- Le processus de build existant crée des AMI pour AWS avec Packer ; une partie de ce pipeline a été réutilisée pour construire l’All In One Image
- L’All In One Image contient, dans un seul conteneur Docker, tous les services nécessaires à l’exécution d’un projet Supabase
Passage au multicloud
- Avec ce lancement, Supabase est officiellement devenu multicloud
- Supabase évite volontairement les services managés d’AWS afin de simplifier le passage au multicloud
- La transition n’est pas simple, car les primitives de base varient fortement d’un fournisseur cloud à l’autre
- Fly Machines offre un mécanisme permettant d’arrêter les VM inutilisées et de les relancer de manière transparente en quelques secondes
- Le processus de mise en pause des bases de données inactives s’en trouve simplifié
- AWS ne dispose pas d’une primitive permettant d’y parvenir directement
- À l’inverse, Fly ne dispose pas de certaines primitives proposées par AWS, ce qui nécessite des contournements
- Fly Machines ne dispose pas de stockage connecté au réseau
- Supabase traite les données des volumes Fly comme des données temporaires
- Pour tous les projets exécutés sur Fly, des sauvegardes physiques sont effectuées avec WAL-G
- Les modifications de la base de données sont diffusées en continu vers S3
- En cas de défaillance d’un hôte ou d’un volume, le projet est restauré sur un nouvel hôte Fly à partir des dernières données S3
Observabilité opérationnelle et déploiement d’images
- Sur AWS, Supabase reçoit les AWS Health events afin de détecter les problèmes d’hôtes
- Sur Fly, les logs des Machines sont envoyés vers Logflare via fly-log-shipper
- Supabase publie l’All In One Image non seulement dans le registre de conteneurs AWS, mais aussi dans le registre Docker de Fly
- La publication dans le registre Docker de Fly améliore la fiabilité et les performances lors du démarrage de projets sur Fly
Extensions Fly et intégration de l’authentification
- Fly fournit une Extensions API pour étendre sa plateforme
- Supabase a ajouté quelques routes à l’API afin de provisionner les utilisateurs et les projets
- Les utilisateurs Fly peuvent accéder au tableau de bord Supabase avec leurs identifiants Fly existants
- L’API Supabase lance un flux OAuth avec Fly pour l’authentification des utilisateurs
- L’équipe Supabase Auth a créé un Fly OAuth provider pour faciliter l’intégration de l’API
Défis restants
- Supabase continuait de traiter plusieurs défis opérationnels avec l’équipe Fly
-
Prise en charge des restrictions réseau
- La fonctionnalité de restrictions réseau nécessite que le conteneur reçoive la bonne adresse IP du client connecté
- Dans la configuration actuelle, le conteneur voit l’adresse IP du proxy Fly au lieu de celle du client
- La connexion passe par le proxy Fly, qui expose le Proxy protocol
- Postgres ne peut pas utiliser directement cette information, et Supabase étudie la possibilité de rendre Supavisor compatible avec proxy-protocol
-
Sauvegardes internes à Fly
- Comme Fly ne fournit pas encore de stockage Blob managé, les sauvegardes des projets Fly sont effectuées vers AWS S3
- Cette approche entraîne des coûts de bande passante entre clouds
- Fly travaille sur Blob Storage
Démarrage et tarification
- Les demandes d’accès à la preview pouvaient être effectuées via le preview form
- Une fois l’organisation ajoutée à la liste d’autorisation, il était possible de commencer avec le Quickstart de la documentation
- Les organisations Fly pouvaient obtenir un projet gratuit
- Les détails de facturation étaient encore en cours d’élaboration, mais les prix ne devaient pas beaucoup changer par rapport à la tarification actuelle de Supabase
1 commentaires
Avis sur Hacker News
Je suis le CEO de Supabase. Le Postgres actuel de Fly est non managé, donc nous travaillons avec Fly pour exploiter un service managé
C’est le même modèle que celui avec l’équipe Upstash pour Fly Redis : https://fly.io/docs/reference/redis/
Nous sommes encore en train de déployer les fonctionnalités de haute disponibilité auprès des testeurs et il n’y a pas de calendrier définitif, mais nous avancerons aussi vite que possible avec l’équipe Fly
Je n’ai pas souvent entendu parler de cas où une entreprise externe intervient pour collaborer afin de gérer une version hébergée du service non hébergé d’une autre entreprise
J’avais regardé Supabase il y a quelque temps, mais je ne comprenais pas bien comment l’API REST de base était créée
Le fait qu’une API d’interaction soit générée automatiquement quand on crée une table semble intéressant, mais dans ce cas je ne sais pas où mettre la logique métier
J’ai aussi regardé les Edge Functions, mais les exemples ressemblaient davantage à du traitement de tâches, donc je ne voyais pas clairement si c’était l’usage prévu, et j’avais l’impression de passer à côté de quelque chose de simple
L’API REST est assez pratique pour agréger des données, comme avec des jointures, mais dès qu’on a besoin de choses comme des transactions, on commence à être bloqué
La sécurité au niveau des lignes (RLS) pour le contrôle d’accès par rôle était aussi pénible, et l’expérience développeur m’a paru décevante
Si les besoins côté DB sont simples, l’API REST est très pratique, mais si vous prévoyez quelque chose de complexe, mieux vaut apprendre PL/pgSQL ou utiliser une connexion DB classique
Pour la plupart des cas, l’option 1 suffit, et les options 2 et 3 sont plutôt des outils supplémentaires à utiliser au besoin
Dans beaucoup de cas d’usage, on peut mettre la logique dans des procédures stockées SQL, et PostgreSQL permet aussi des procédures stockées en JS ou en Python
Cela dit, pour le code de logique, l’expérience développeur est meilleure quand on le déploie sous forme de conteneurs CI/CD classiques ou de fonctions, et les deux approches sont beaucoup utilisées selon les compromis de coût
Supabase recommande les fonctions serverless Deno, mais pour un projet web, je pense que la majorité préférera déployer des fonctions Node sur Cloudflare
Au final, le public visé semble être celui qui met 99 % de la logique dans le frontend JS et veut que le backend ne gère que le CRUD et l’authentification
Pour cette partie, nous avons créé un système d’événements basé sur le WAL de Postgres, que nous traitons comme un système de callbacks
Nous avons aussi créé une petite bibliothèque pour Elixir, partie à l’origine d’un fork de Supabase Realtime : https://github.com/cpursley/walex
Récemment, nous avons ajouté la possibilité de configurer WalEx pour transmettre les événements à des webhooks ou à EventRelay, afin qu’il ne soit pas nécessaire de connaître Elixir
Comme nous utilisons Next.js, une bonne partie des appels à la DB se trouve dans des fonctions serverless Next
J’envisage aussi de déplacer une partie de la logique vers des fonctions Supabase pour la placer aussi près que possible de la DB, mais je n’avais pas encore envie de passer à Deno
Quand on accède à Supabase depuis le serveur, on peut utiliser les fonctionnalités PostgREST utilisées par le client Supabase, ou accéder directement à Postgres avec la bibliothèque classique
pgJ’ai hâte de migrer vers ça. En construisant Booklet sur Fly.io et Fly Postgres, j’ai conçu l’app de manière distribuée : https://www.contraption.co/essays/booklet-architecture/
Le plus gros problème a été la configuration de Fly Postgres. En particulier, Fly place HAProxy devant Postgres et impose une limite de connexion de 30 minutes, ce qui coupe sans cesse les connexions : https://community.fly.io/t/postgresql-connection-issues-have...
Cela devrait être un problème maîtrisable, mais le comportement de fermeture des connexions ne correspond pas à la documentation, avec des aspects étranges, ce qui rend l’ensemble instable
Je me demande si le nouveau Postgres mettra aussi le même HAProxy en frontal
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
J’ai vu ça aujourd’hui dans la documentation Fly et je me suis demandé si je l’avais raté sur HN, mais c’était bien tout nouveau
Ma deuxième réflexion, c’est qu’il est étrange de voir Postgres by Fly et Postgres by Supabase côte à côte dans la barre latérale
Il n’y a pas non plus de comparaison bien visible, donc si l’on déploie une app sur Fly et qu’on a besoin de Postgres, on ne sait pas trop quoi choisir
Personnellement, si j’ai besoin d’un DBMS sur Fly, j’utiliserais SQLite distribué avec LiteFS, et si j’ai besoin de Postgres, la différence entre Fly et Supabase me semble être essentiellement non managé contre managé
Très bien. Je n’aimais pas beaucoup les réglages de restriction réseau de Supabase : https://supabase.com/docs/guides/platform/network-restrictio...
Dans mon souvenir, quand j’avais regardé ça, il y avait un problème étrange pour exposer l’IP d’une app Fly à Supabase et verrouiller Supabase sur cette IP
Le fait que Supabase entre réellement dans le réseau Fly est excellent
C’est aussi indiqué dans la documentation réseau de Fly.io
J’ai entendu dire que Supabase avait des problèmes de scalabilité une fois passé le stade du prototype ; je me demande si quelqu’un ayant une expérience en production peut en parler
De quels problèmes précis parles-tu ?
Joshua, de Fly.io. Si vous avez des questions sur cette intégration, je peux y répondre
Je l’utilise pour quelques projets perso, mais pas encore pour de gros projets
La prochaine chose que j’aimerais, c’est du stockage Blob ; comme je préfère par défaut utiliser du managé pour tout ce qui est stateful, je suis content que ce soit aussi en cours
Je me demande s’il y a des détails sur les tarifs de la nouvelle offre Postgres
Nous faisons actuellement tourner une grosse base de données sur Fly et cherchons du PostgreSQL managé, donc cette nouvelle nous réjouit beaucoup
Nous sommes une équipe entièrement Elixir, le timing ne pourrait donc pas être meilleur
« Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral. »
N’ayant jamais utilisé AWS et ne connaissant pas bien le stockage connecté au réseau, je me demande en quoi les volumes Fly diffèrent exactement du stockage connecté au réseau d’autres fournisseurs
Il me semble que lorsqu’on crée un volume Fly, on peut le déplacer vers un autre serveur de la même région ; techniquement, ce n’est donc pas du stockage connecté au réseau ?
En interne, nous pouvons déplacer un volume d’un hôte physique à un autre ; la méthode est assez intéressante, mais nous ne l’avons pas encore beaucoup exposée publiquement
Nous prévoyons de la rendre plus visible cette année
Les Fly Volumes sont sauvegardés régulièrement vers du stockage bloc hors réseau, et d’autres annonces à ce sujet devraient aussi arriver bientôt
Ce qu’il faut comprendre, fondamentalement, c’est que les Fly Volumes ne sont pas du stockage SAN, ni un stockage intrinsèquement fiable comme S3
Dans les Fly Machines, ils apparaissent comme un simple système de fichiers ext4, et si vous avez besoin de fiabilité, de durabilité ou de réplication, vous devez les fournir au niveau applicatif
Fly Postgres fonctionne comme un cluster avec réplicas en lecture, et n’importe quel réplica peut prendre le rôle de leader en écriture si nécessaire ; c’est donc le bon modèle
C’est aussi pour cette raison que nous affichons un gros avertissement rouge dans la console quand vous essayez de créer un cluster Postgres à nœud unique
Dans les prochains trimestres, nous proposerons probablement de nouvelles options sur le spectre fiabilité/performance, mais il est peu probable que cela prenne la forme d’une exploitation directe de disques SAN exposant seulement des périphériques bloc façon iSCSI
Je déteste vraiment les modèles de tarification de ces deux entreprises
À une extrémité, il y a Supabase, avec une offre par paliers de type plateforme développeur à la Vercel, structurée pour vous faire payer plus que votre usage réel
À l’autre extrémité, il y a Fly, avec une tarification trop granulaire, à la seconde, à la mémoire et au CPU, façon Lambda, qui risque probablement de vous faire payer trop peu et de subir des baisses de performances
Avec des options comme Cloudflare Workers, je ne comprends pas bien pourquoi choisir l’un des deux. Pourquoi vouloir encore se soucier du scaling ?
Il me semble aussi peu probable que Cloudflare propose un vrai Postgres. La philosophie de Cloudflare est plutôt que tout ce que vous déployez est déployé dans le monde entier, alors qu’une base de données relationnelle impose un serveur unique comme source de vérité
Cela dit, j’aimerais bien qu’on me prouve le contraire
Les prix mensuels de Fly sont assez intuitifs et ne ressemblent pas du tout à Lambda. Des deux, c’est plutôt le modèle tarifaire de Cloudflare Workers qui est le plus proche de Lambda