Von Supabase verwaltetes Fly Postgres

 (supabase.com)
2 Punkte von GN⁺ 2023-12-17 | 1 Kommentare | Auf WhatsApp teilen
  • Die Zusammenarbeit von Supabase und Fly.io bei verwaltetem Postgres war ein Versuch, die Datenbankfunktionen von Supabase auf der Fly-Infrastruktur nutzbar zu machen, wurde inzwischen jedoch eingestellt.
  • Der Dienst sollte Postgres in einer Edge-Computing-Umgebung bereitstellen, die in mehr als 37 Standorten von Fly.io läuft, um Fly-Anwendungen und Datenbanken näher zusammenzubringen.
  • Der Funktionsumfang umfasste mehr als 40 Erweiterungen, pgvector, Supavisor, tägliche Backups, Point-in-Time-Recovery, Branching, Observability, Migrationen, ein Dashboard sowie automatisch generierte REST- und GraphQL-APIs.
  • Die anfängliche Bereitstellung sollte schrittweise erfolgen; offen waren noch Integrationsarbeiten zwischen den Unternehmen wie Abrechnung, Support-Übergabe, interne Schulungen sowie Fehlerbehebungen aus den ersten Tests.
  • Während das bisherige Postgres-Angebot von Fly unverwaltet war und die Betriebsverantwortung bei den Nutzern lag, war Fly Postgres ein verwalteter Dienst, bei dem Supabase Skalierung, Backups, Replikation und Upgrades übernahm.

Veröffentlichungsstatus und Leistungsumfang

  • Fly Postgres wurde inzwischen eingestellt; weitere Details stehen in der Ankündigung zur Einstellung.
  • Supabase und Fly.io veröffentlichten Fly Postgres als verwalteten Postgres-Dienst, der auf der Fly-Infrastruktur läuft.
  • Die Datenbank lief auf der Edge-Computing-Plattform von Fly.io und konnte beim Start aus mehr als 37 Standorten von Fly.io gewählt werden.
  • Datenintensive Anwendungen, die auf Fly bereitgestellt wurden, konnten mit geringerer Latenz rechnen, wenn sich die Datenbank in derselben Infrastruktur befand.

Funktionen des von Supabase verwalteten Postgres

  • Fly Postgres brachte die zentralen Funktionen, die man von einer verwalteten Supabase-Datenbank erwartet, in die Fly-Umgebung.
    • Mehr als 40 Erweiterungen aus Supabase Postgres
    • Unterstützung für Vector-/AI-Workloads auf Basis von pgvector
    • Supavisor als Postgres-Connection-Pooler von Supabase
    • Tägliche Backups und Point-in-Time-Recovery
    • Branching, Observability, Migrationen
    • Dashboard zur Datenbankverwaltung
    • Automatisch generierte Data API

Schrittweiser Rollout und erste Tests

  • Die Veröffentlichung erfolgte als schrittweiser Rollout.
  • Die Integration zwischen den Unternehmen umfasste Aufgaben wie Abrechnung, Support-Übergabe und Schulungen für Supabase-Mitarbeitende.
  • Das Angebot wurde mit einigen frühen Testern validiert, und es gab noch zu behebende Bugs.
  • Wer an Tests teilnehmen wollte, konnte sich auf die Waitlist setzen lassen.
  • Für den folgenden Monat war die Aufnahme weiterer Tester geplant; zusätzliche Veröffentlichungspläne sollten nach Bestätigung der Datensicherheit geteilt werden.

Unterschied zwischen verwaltetem und unverwaltetem Postgres

  • Das bisherige Postgres-Angebot von Fly war unverwaltet.
    • Nutzer mussten sich selbst um Skalierung, Point-in-Time-Backups, Replikation und größere Versions-Upgrades kümmern.
  • Mit dem von Supabase betriebenen verwalteten Postgres auf Fly konnten sich Nutzer stärker auf den Bau ihrer Anwendungen konzentrieren.
  • Der verwaltete Dienst wurde mit der Fly extension API erstellt.
    • Dieselbe API wird auch für Fly Redis verwendet.
  • Tester konnten mit dem Befehl fly extensions eine Postgres-Datenbank erstellen.
    • fly extensions supabase create
  • Nach Stabilisierung des Dienstes sollte dies durch den postgres-Namespace ersetzt werden.
    • fly postgres create

Implementierung auf Basis von Fly Machines

  • Fly Postgres wurde auf Fly machines aufgebaut.
  • Machines sind schlanke Firecracker-VMs, und die Machines API erlaubt eine feingranulare Steuerung des Anwendungslebenszyklus.
  • Machines können im inaktiven Zustand angehalten und bei neuen Anfragen innerhalb weniger Sekunden wieder gestartet werden.
  • Um die Interaktion mit der Fly API zu vereinfachen, entwickelte Supabase den TypeScript-Wrapper fly-admin.
  • Da Supabase einige zusätzliche Dienste mit Postgres bündelt, wurde ein einzelnes Docker-Image vorbereitet, das an die Fly Machines API übergeben werden kann.
  • Der bestehende Build-Prozess erzeugte mit Packer ein AMI für AWS; Teile dieser Pipeline wurden wiederverwendet, um das All In One Image zu bauen.
  • Das All In One Image enthält alle Dienste, die zum Ausführen eines Supabase-Projekts in einem einzelnen Docker-Container benötigt werden.

Umstellung auf Multicloud

  • Mit dieser Veröffentlichung wurde Supabase offiziell Multicloud.
  • Supabase vermied bewusst verwaltete AWS-Dienste, um den Wechsel zu Multicloud zu vereinfachen.
  • Da sich die grundlegenden Primitive je nach Cloud-Anbieter stark unterscheiden, ist der Umstieg nicht einfach.
  • Fly Machines bieten die Möglichkeit, ungenutzte VMs anzuhalten und innerhalb weniger Sekunden transparent wieder aufzunehmen.
    • Dadurch wird das Pausieren inaktiver Datenbanken einfacher.
    • In AWS gibt es kein direkt entsprechendes Primitive.
  • Umgekehrt fehlen bei Fly einige Primitive, die AWS bietet, sodass Workarounds nötig sind.
    • Fly Machines haben keinen netzwerkgebundenen Storage.
    • Supabase behandelt die Daten auf Fly Volumes als temporäre Daten.
    • Für alle auf Fly laufenden Projekte werden physische Backups mit WAL-G erstellt.
    • Datenbankänderungen werden fortlaufend nach S3 gestreamt.
    • Bei Schäden an Host oder Volume wird das Projekt mithilfe der neuesten Daten aus S3 auf einem neuen Fly-Host wiederhergestellt.

Betriebsbeobachtung und Image-Verteilung

  • In AWS werden AWS Health events empfangen, um Host-Probleme zu erkennen.
  • Bei Fly werden Machine-Logs über fly-log-shipper an Logflare gesendet.
  • Supabase veröffentlicht das All In One Image nicht nur in der AWS-Container-Registry, sondern auch in der Fly-Docker-Registry.
  • Durch die Veröffentlichung in der Fly-Docker-Registry verbessern sich Zuverlässigkeit und Performance beim Starten von Projekten auf Fly.

Fly-Erweiterungen und Auth-Integration

  • Fly bietet die Extensions API für Plattformerweiterungen an.
  • Supabase fügte der API einige Routen hinzu, um Nutzer und Projekte zu provisionieren.
  • Fly-Nutzer konnten mit ihren bestehenden Fly-Zugangsdaten auf das Supabase-Dashboard zugreifen.
  • Die Supabase API startete einen OAuth-Flow mit Fly zur Benutzerauthentifizierung.
  • Das Supabase-Auth-Team entwickelte den Fly OAuth provider, um die API-Integration zu erleichtern.

Offene Aufgaben

  • Supabase arbeitete gemeinsam mit dem Fly-Team weiter an einigen operativen Aufgaben.

  • Unterstützung für Netzwerkbeschränkungen

    • Netzwerkbeschränkungen funktionieren nur, wenn der Container die korrekte IP des zugreifenden Clients erhält.
    • In der aktuellen Konfiguration sieht der Container statt der Client-IP die Fly-Proxy-IP.
    • Verbindungen laufen über den Fly-Proxy, der das Proxy Protocol bereitstellt.
    • Postgres kann diese Information nicht direkt nutzen; Supabase prüfte daher, wie Supavisor für das Proxy Protocol sensibilisiert werden kann.

  • Interne Backups bei Fly

    • Da Fly noch keinen verwalteten Blob-Storage anbietet, werden Backups von Fly-Projekten nach wie vor in AWS S3 gespeichert.
    • Das verursacht Bandbreitenkosten zwischen Clouds.
    • Fly arbeitet an Blob Storage.

Einstieg und Preise

  • Eine Vorschau konnte über das Preview-Formular beantragt werden.
  • Sobald eine Organisation zur Allowlist hinzugefügt wurde, konnte sie über den Quickstart in der Dokumentation loslegen.
  • Fly-Organisationen konnten ein kostenloses Projekt erhalten.
  • Details zur Abrechnung waren noch in Arbeit, doch gegenüber den aktuellen Supabase-Preisen waren keine großen Änderungen zu erwarten.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-17
Hacker-News-Kommentare

  • Ich bin CEO von Supabase. Das aktuelle Postgres von Fly ist unmanaged, daher arbeiten wir daran, gemeinsam mit Fly einen Managed Service zu betreiben.
    Das ist dasselbe Modell wie mit dem Upstash-Team bei Fly Redis: https://fly.io/docs/reference/redis/
    Wir rollen die Hochverfügbarkeitsfunktionen noch mit Testern aus und haben keinen festen Zeitplan, werden das aber mit dem Fly-Team so schnell wie möglich vorantreiben.

    • Ich frage mich, warum Fly nicht wie DigitalOcean oder die großen Clouds eigene Managed Services anbietet und in den gehobeneren Markt aufsteigt.
      Ich habe selten von Fällen gehört, in denen ein externes Unternehmen hereinkommt und zusammenarbeitet, um eine gehostete Version eines nicht gehosteten Dienstes eines anderen Unternehmens zu verwalten.
    • Ich würde gern wissen, wie ihr verteiltes SQLite seht. Glaubt ihr, dass es künftig zur Standardwahl statt Postgres werden kann?

  • Ich hatte mir Supabase früher angesehen, war aber verwirrt, wie die grundlegende REST API erstellt wird.
    Dass beim Erstellen einer Tabelle automatisch eine API zur Interaktion erzeugt wird, klingt gut, aber dann wusste ich nicht, wohin die Geschäftslogik soll.
    Ich habe mir auch Edge Functions angesehen, aber die Beispiele wirkten eher wie Job-Processing, daher war nicht klar, ob sie dafür gedacht sind; ich hatte das Gefühl, etwas Einfaches zu übersehen.

    • Wenn man das PostgREST-Interface nutzt, muss man bedenken, dass man die Logik am Ende in Stored Procedures legt.
      Die REST API ist für Datenaggregation wie Joins ziemlich praktisch, aber sobald man Dinge wie Transaktionen braucht, stößt man an Grenzen.
      Auch Row Level Security (RLS) für rollenbasierte Zugriffskontrolle war umständlich, und die Developer Experience war enttäuschend.
      Wenn die DB-Anforderungen einfach sind, ist die REST API sehr praktisch; wenn man aber Komplexes plant, ist es besser, PL/pgSQL zu lernen oder eine normale DB-Verbindung zu verwenden.
    • Es gibt mehrere Optionen: sich wie bei einer normalen Postgres-DB direkt mit Postgres verbinden, das erwähnte automatisch generierte REST API namens PostgREST nutzen oder Deno-basierte Edge Functions verwenden.
      Für die meisten reicht Option 1, und 2 und 3 sind eher zusätzliche Werkzeuge, die man bei Bedarf einsetzt.
    • Der Kernbaustein ist https://postgrest.org/en/stable/. Wir nutzen es produktiv in einem Enterprise-Projekt auf k8s.
      In vielen Use Cases kann man die Logik in SQL-Stored-Procedures unterbringen, und PostgreSQL unterstützt auch JS- oder Python-Stored-Procedures.
      Für Logik-Code ist die Developer Experience jedoch meist besser, wenn man ihn als normale CI/CD-Container oder Functions deployt; je nach Kostenabwägung werden beide Ansätze häufig genutzt.
      Supabase empfiehlt serverlose Deno-Funktionen, aber bei Webprojekten würden die meisten wohl eher Node-Funktionen auf Cloudflare deployen.
      Letztlich scheint die Zielgruppe diejenige zu sein, die 99 % der Logik im JS-Frontend belässt und das Backend nur CRUD und Authentifizierung erledigen lässt.
    • Wir legen einen erheblichen Teil der Geschäftslogik in Trigger und Constraints von Postgres. Es gibt allerdings auch andere Aufgaben wie externe Integrationen.
      Dafür haben wir ein Event-System auf Basis des Postgres-WAL gebaut und es wie ein Callback-System behandelt.
      Wir haben auch eine kleine Bibliothek für Elixir erstellt, die ursprünglich als Fork von Supabase Realtime begonnen hat: https://github.com/cpursley/walex
      Kürzlich haben wir die Möglichkeit hinzugefügt, WalEx so zu konfigurieren, dass Events an Webhooks oder EventRelay weitergeleitet werden, ohne dass man Elixir kennen muss.
    • Je nach Konfiguration kann man von Client und Server aus auf die DB zugreifen.
      Da wir Next.js verwenden, liegen viele unserer DB-Aufrufe in serverlosen Next-Funktionen.
      Ich werde mir aber auch ansehen, etwas Logik in Supabase Functions zu verschieben, um sie möglichst nah an der DB zu halten; bisher wollte ich allerdings noch nicht zu Deno wechseln.
      Wenn man vom Server aus auf Supabase zugreift, kann man entweder die PostgREST-Funktionen nutzen, die der Supabase-Client verwendet, oder über die übliche pg-Bibliothek direkt auf Postgres zugreifen.

  • Ich freue mich darauf, darauf umzusteigen. Ich habe Booklet auf Fly.io und Fly Postgres gebaut und die App verteilt aufgebaut: https://www.contraption.co/essays/booklet-architecture/
    Das größte Problem war die Einrichtung von Fly Postgres. Insbesondere setzt Fly HAProxy vor Postgres und erzwingt ein Verbindungslimit von 30 Minuten, wodurch Verbindungen ständig getrennt werden: https://community.fly.io/t/postgresql-connection-issues-have...
    Das sollte eigentlich handhabbar sein, aber das Verhalten beim Schließen von Verbindungen stimmt auf merkwürdige Weise nicht mit der Dokumentation überein, was es dauerhaft instabil macht.
    Ich frage mich, ob auch das neue Postgres denselben HAProxy davor haben wird.

  • Ich habe das heute in der Fly-Dokumentation gesehen und mich gefragt, ob ich es auf HN verpasst hatte, aber es war tatsächlich neu.
    Mein zweiter Gedanke war, dass es seltsam ist, Postgres by Fly und Postgres by Supabase gemeinsam in der Seitenleiste zu sehen.
    Es gibt auch keinen auffälligen Vergleich, daher ist es verwirrend, was man verwenden soll, wenn man eine App auf Fly deployt und Postgres braucht.
    Persönlich würde ich, wenn ich auf Fly ein DBMS brauche, wohl LiteFS Distributed SQLite nutzen; wenn ich Postgres brauche, sehe ich den Unterschied zwischen Fly und Supabase im Grunde als unmanaged vs. managed.

    • Wenn du eine Managed Database brauchst, nimm Supabase. Fly.io Postgres ist unmanaged, das ist tatsächlich der zentrale Unterschied.

  • Sehr gut. Die Einstellungen für Netzwerkbeschränkungen von Supabase mochte ich nicht besonders: https://supabase.com/docs/guides/platform/network-restrictio...
    Als ich mir das früher angesehen habe, erinnere ich mich, dass es irgendein merkwürdiges Problem damit gab, die IP einer Fly-App gegenüber Supabase offenzulegen und Supabase auf diese IP festzunageln.
    Dass Supabase tatsächlich ins Fly-Netzwerk kommt, ist großartig.

    • Das Problem dabei ist, dass fly.io keine Konsistenz bei ausgehenden IP-Adressen garantiert, sodass man keine Allowlist auf Basis der Quell-IP verwenden kann.
      Das steht auch in der Networking-Dokumentation von Fly.io.

  • Ich habe gehört, dass Supabase jenseits von Prototypen Skalierungsprobleme hat; mich würde interessieren, ob jemand mit Produktionserfahrung dazu etwas sagen kann.

    • Da es Postgres auf AWS ist, würde ich erwarten, dass es ungefähr so skaliert, wie man es von dieser Kombination erwartet.
      Welche konkreten Probleme meinst du?

  • Joshua von Fly.io hier. Wenn ihr Fragen zu dieser Integration habt, beantworte ich sie gern.

    • Darauf freue ich mich wirklich. Abgesehen von allgemeinen Stabilitätsbedenken, besonders rund um Deployments, und schwer verständlichen Fehlermeldungen war das Fehlen von Managed Postgres der Hauptgrund, warum ich Fly nicht ernsthaft nutze.
      Für ein paar Nebenprojekte verwende ich es, aber noch nicht für größere Projekte.
      Als Nächstes wünsche ich mir Blob Storage; bei zustandsbehafteten Dingen möchte ich grundsätzlich Managed-Angebote nutzen, daher freut es mich, dass auch daran gearbeitet wird.
      Ich frage mich, ob es Details zu den Preisen des neuen Postgres-Angebots gibt.

  • Wir betreiben derzeit eine große DB auf Fly und suchen nach Managed PostgreSQL, daher freue ich mich sehr über diese Nachricht.
    Wir sind ein reines Elixir-Team, also könnte das Timing kaum besser sein.

    • Ich frage mich, welchen Vorteil das gegenüber einer einfachen Anmeldung bei supabase.com und dem Eintragen der DB-Zugangsdaten in die Elixir-App hat.

  • “Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
    Ich habe AWS nie genutzt und kenne mich mit netzwerkgebundenem Storage nicht gut aus, daher frage ich mich, worin genau der Unterschied zwischen Fly Volumes und netzwerkgebundenem Storage anderer Anbieter liegt.
    Wenn man ein Fly Volume erstellt, konnte man es doch, glaube ich, auf einen anderen Server in derselben Region verschieben; ist das dann technisch gesehen nicht netzwerkgebundener Storage?

    • Nein. Fly Volumes sind angebundener NVMe-Storage und an den physischen Host gebunden, auf dem sie erstellt wurden.
      Intern können wir Volumes von einem physischen Host auf einen anderen verschieben; die Methode dafür ist ziemlich interessant, aber wir haben sie öffentlich noch nicht groß sichtbar gemacht.
      Im Laufe dieses Jahres werden wir davon mehr an die Oberfläche bringen.
      Fly Volumes werden regelmäßig auf Off-Network-Block-Storage gesichert, und dazu wird es bald ebenfalls weitere Ankündigungen geben.
      Grundsätzlich muss man verstehen, dass Fly Volumes kein SAN-Storage sind und auch kein inhärent zuverlässiger Storage wie S3.
      Innerhalb von Fly Machines erscheinen sie als einfaches ext4-Dateisystem, und wenn man Zuverlässigkeit, Dauerhaftigkeit und Replikation braucht, muss die Anwendungsschicht das bereitstellen.
      Fly Postgres läuft als Cluster mit Read Replicas, und bei Bedarf kann jede Replik die Rolle des Write Leaders übernehmen; deshalb passt dieses Modell.
      Das ist auch der Grund, warum wir in der Konsole eine große rote Warnung anzeigen, wenn jemand versucht, einen Single-Node-Postgres-Cluster zu erstellen.
      In den nächsten Quartalen werden wir vermutlich neue Optionen entlang des Spektrums von Zuverlässigkeit und Performance anbieten, aber es wird wohl nicht darauf hinauslaufen, selbst SAN-Laufwerke zu betreiben, die nur Block Devices im Stil von iSCSI bereitstellen.

  • Ich mag die Preismodelle dieser beiden Unternehmen wirklich nicht.
    Am einen Ende steht Supabase, mit einem gestaffelten Angebot im Stil von Entwicklerplattformen wie Vercel, das einen dazu bringt, mehr zu bezahlen, als der tatsächlichen Nutzung entspricht.
    Am anderen Ende steht Fly, mit einer übermäßig feingranularen Preisgestaltung pro Sekunde, Speicher und CPU wie bei Lambda, sodass man wahrscheinlich zu wenig bezahlt und dafür Performance-Einbußen erlebt.
    Wenn es Dinge wie Cloudflare Workers gibt, verstehe ich nicht recht, warum man sich für eines von beiden entscheiden sollte. Warum sollte man sich immer noch um Skalierung sorgen wollen?

    • Cloudflare Workers haben keine Postgres-Option. Im besten Fall gibt es Hyperdrive, das eine Verbindung zu anderswo gehostetem Postgres herstellt, aber das ist im Kern ein Connection Pooler und bringt zusätzliche Einschränkungen mit sich.
      Es wirkt auch unwahrscheinlich, dass Cloudflare echtes Postgres anbieten wird. Cloudflares Philosophie geht eher dahin, dass alles, was man deployt, weltweit verteilt wird; relationale Datenbanken erzwingen dagegen einen einzelnen Server als Source of Truth.
      Ich würde mich natürlich freuen, wenn ich damit falschliege.
    • Versuch mal, beliebige Docker-Container, die du brauchst, auf Cloudflare Workers laufen zu lassen, dann siehst du den Grund.
      Die monatlichen Preise von Fly sind ziemlich übersichtlich und haben überhaupt nichts mit Lambda gemein. Wenn überhaupt, ist von den beiden das Preismodell von Cloudflare Workers näher an Lambda.
    • Letztlich wegen des PostgreSQL-Ökosystems, der Developer Experience und diverser Zusatzfunktionen.