PGlite: WASM-Postgres, das im Browser läuft

 (pglite.dev)
2 Punkte von GN⁺ 2024-08-13 | 1 Kommentare | Auf WhatsApp teilen
  • Ermöglicht es, vollständiges Postgres in Local-first-Apps und browserbasierten Entwicklungsumgebungen direkt als WASM auszuführen und so die Serverabhängigkeit zu reduzieren
  • Wird als Build mit unter 3 MB Gzip-Größe bereitgestellt und lässt sich damit leicht in Browser- und lokale Umgebungen einbetten
  • Über dynamisches Laden von Erweiterungen können Postgres-Erweiterungen wie pgvector und PostGIS genutzt werden
  • Integrierte Primitive für Datenladen, Synchronisierung und Live Queries sind auf reaktive Apps und Echtzeit-Anwendungsfälle ausgelegt
  • Supabases database.build bietet auf Basis von PGlite eine Erfahrung, mit der sich mithilfe von AI Postgres-Datenbanken erstellen und veröffentlichen lassen

Postgres im Browser und lokal nutzen

  • PGlite ist ein eingebettetes Postgres, das eine vollständige Postgres-Datenbank lokal in WASM ausführt
  • Es ist ein vollständiger Postgres-WASM-Build und wird Gzip-komprimiert mit unter 3 MB bereitgestellt
  • Integrierte Primitive für Datenladen, Synchronisierung und Live Queries ermöglichen clientzentrierte, reaktive Datenflüsse

Erweiterungen und Experimentierumgebung

  • Unterstützt einen Mechanismus zum dynamischen Laden von Erweiterungen
    • einschließlich pgvector
    • Auch PostGIS kann genutzt werden
  • Im Playground lassen sich weitere Erweiterungen ausprobieren
  • Auf der aktuellen Seite kann man direkt das vollständige PGlite Postgres ausprobieren, das im Browser läuft; pgvector ist ebenfalls enthalten

Dokumentation und Distributionskanäle

  • In Get Started findet sich die Einstiegsdokumentation
  • GitHub zeigt 15,5K Sterne an
  • NPM zeigt 10,1 Mio. wöchentliche Downloads an

Supabases database.build

  • database.build ist ein von Supabase auf Basis von PGlite erstellter Dienst
  • Bietet einen Workflow, mit dem man Postgres-Datenbanken per AI erstellen und veröffentlichen kann

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-13
Meinungen auf Hacker News

  • Ich hatte früher schon gesehen, dass es im Browser läuft, und fand beeindruckend, dass dafür nur etwa 3 MB Download nötig sind. Dass es auch serverseitig mit Node.js und Bun läuft, war mir aber entgangen: https://pglite.dev/docs/
    Da kein echter Netzwerkserver gestartet wird, fühlt es sich wie eine Alternative zu SQLite an. Spannend ist, dass man direkt in einer bestehenden Node.js-/Bun-App eine In-Process-PostgreSQL-Implementierung starten kann, die auf die Festplatte persistiert
    Ich würde es auch gern in Python mit Wrappern wie https://github.com/wasmerio/wasmer-python oder https://github.com/bytecodealliance/wasmtime-py ausprobieren und frage mich, ob PGlite schon jemand auf diese Weise betrieben hat

    • PGlite in anderen Sprachen gut zum Laufen zu bringen, hat sehr hohe Priorität
      Wir verfolgen zwei Ansätze: Der eine ist ein WASI-Build einer Low-Level-API, die Nutzer mit einer High-Level-API umhüllen können, der andere ist libpglite, das sich aus nativen Sprachen linken lässt
      Die meisten Sprachen haben bereits Implementierungen des Postgres-Wire-Protokolls; daher ist es relativ einfach, eine Low-Level-API zu umhüllen, die dieses Protokoll liest und ausgibt. Auch die JS-Seite von PGlite funktioniert auf diese Weise
    • Als Zwischenlösung scheint es möglich, in Python per subprocess ein Node.js-Skript aufzurufen, das exec und query von @electric-sql/pglite ausführt, und die Ergebnisse als JSON hin und her zu reichen
      Die Struktur wäre, in db.js eine PGlite-Instanz zu erstellen, SQL und Parameter als Kommandozeilenargumente entgegenzunehmen und zu verarbeiten, und dann in main.py node db.js exec ... oder node db.js query ... aufzurufen
    • Ich würde PGlite auch gern in Python nutzen, und beim Lesen dieses Threads wurde mir klar, dass es über Pyodide bereits zugänglich ist
      Pyodide ist ein Wasm-Port von CPython und kann über Proxys mit JavaScript-Objekten interagieren
      Im Beispiel wurde globalThis.db = new PGlite() erstellt und anschließend aus Python-Code js.db.query() per await aufgerufen, um SELECT 'Hello, world!' AS "greeting"; auszuführen; aktuell funktionierte es mit Node.js 18, Deno 1 und Bun 1
    • Es wäre schön, wenn jemand, der sich mit Lizenzen besser auskennt, erklären könnte, welche Auswirkungen das auf kommerzielle Projekte oder Lösungen hat und wie es sich etwa mit embedded FirebirdSQL vergleicht
      Ich frage mich zum Beispiel, ob man es in kommerziellen Projekten ohne Offenlegung des Quellcodes verwenden kann und ob man beim Einbetten die Lizenz an pg/fb anpassen muss
      Wenn ich es konkret brauche, würde ich es selbst prüfen, aber einige Punkte, die mir an der Einfachheit von SQLite nicht gefallen, ähneln ziemlich den Dingen, die ich an MySQL/MariaDB nicht mag, daher bin ich neugierig
    • Es ist spannend, wie gut das in der Praxis funktionieren wird
      Ich weiß nicht, wie sie die Persistenzschicht von PostgreSQL angepasst haben, aber im Vergleich dazu, PostgreSQL in einem Docker-Container laufen zu lassen, scheint es Einschränkungen geben zu können
      SQLite hat solche Einschränkungen nicht

  • Ich mag PGlite wirklich sehr
    Es ist die perfekte Lösung, um Postgres ohne Docker zu haben, und weil man mit nur npm install eine Postgres-Instanz auf dem lokalen Rechner erstellen kann, ist es sehr einfach, neue Entwickler ins Team einzuarbeiten
    Es funktioniert auch gut mit Next.js, und ich nutze es in lokalen und Entwicklungsumgebungen zusammen mit dem Next.js Boilerplate: https://github.com/ixartz/Next-js-Boilerplate
    Mit einem einzigen npm install steht eine Full-Stack-Anwendung inklusive Datenbank bereit, also ein funktionierendes Postgres, ohne dass externe Tools installiert werden müssen

    • Normalerweise handhaben wir Entwicklungsabhängigkeiten mit docker compose, aber das sieht definitiv nach einer tollen Alternative aus

  • Damit die Nächsten es nicht selbst nachschlagen oder fragen müssen: Für Persistenz auf Browser-Seite werden IndexedDB und OPFS unterstützt: <https://pglite.dev/docs/filesystems>

    • Deine und Roys Arbeit an WASM SQLite VFS hatte direkten Einfluss auf diese Arbeit

  • Als ich den Titel sah, dachte ich sofort: „Das würde wirklich gut zu ElectricSQL passen“, und es ist schön zu sehen, dass es tatsächlich von ElectricSQL kommt
    Die unmittelbare Developer Experience ist hervorragend, und ich möchte PGlite und ElectricSQL in einem Produktionsprojekt ausprobieren
    Es dürfte viele der Unannehmlichkeiten verringern, mit denen ich derzeit zu kämpfen habe, und persönlich arbeite ich auch gern mit CRDT

  • Glückwunsch zu Show HN
    Ich habe den ElectricSQL-Discord-Server verfolgt und war besonders daran interessiert, es in anderen Sprachen als TypeScript zu nutzen; daher freut es mich, dass Sprachunabhängigkeit bei euch Priorität hat.
    Ich habe gesehen, dass ElectricSQL wegen Architekturänderungen neu geschrieben wird, und frage mich, ob das Auswirkungen auf PGlite hat oder ob es inzwischen ein separates Projekt ist.
    Außerdem ist SQLite eigentlich SQL-ite, also aus der -ite-Familie wie „urbanite“, aber durch Rebracketing und Libfixing scheint es heute von vielen wie ein -lite-Suffix verwendet zu werden.
    Das könnte daran liegen, dass lite semantisch klarer ist, ite aber nicht; ähnlich wie „helicopter“ ursprünglich helic + opter war, aber als heli + copter verstanden wurde und so Wörter wie „helipad“ oder „quadcopter“ entstanden sind.
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite und Electric sync sind separate Projekte, aber wir machen PGlite zu einem Sync-Ziel für Electric.
      Die Änderungen bei Electric gehen weg vom früher stark integrierten Stack hin zu einem lockerer gekoppelten Stack.
      PGlite ist einer der möglichen clientseitigen Stores für Electric sync und deckt Use Cases ab, bei denen man eine vollständige SQL-Datenbank auf dem Client hat und auf Client und Server sogar dasselbe Schema verwenden kann.
      Der Name ist natürlich eine Hommage an SQLite; das kleine l dient als kleine Differenzierung und als Anspielung auf „light“, und es steckt auch die Bedeutung eines leichtgewichtigen Postgres darin.

  • Früher hätte ich gesagt, der Hauptunterschied zwischen PostgreSQL und SQLite sei, dass SQLite in-process läuft. Wenn jetzt aber beide in-process möglich sind, frage ich mich, ob es Material gibt, das die beiden genauer vergleicht.
    In welchen Situationen sollte man das eine dem anderen vorziehen?

    • SQLite ist seit sehr langer Zeit bewährt, aber bei PGlite habe ich nach nicht einmal drei Minuten ein memory access out of bounds gesehen.
      Auch wenn der große Bruder PostgreSQL zu den robustesten Datenbanken gehört, könnte es noch schwer sein, es als produktionsreif anzusehen.
      Natürlich habe ich auch bei SQLite schon Probleme gesehen und erlebt; fehlerfreie Software gibt es nicht.
    • Diesen Vergleich würde ich wirklich gern sehen.

  • Ich habe pglite kürzlich in einem Nebenprojekt für API-Integrationstests verwendet, und es hat ziemlich gut funktioniert.
    Die Developer Experience war deutlich besser, als etwas wie testcontainers[0] zu nutzen, um Postgres in Docker hochzufahren.
    [0]: https://testcontainers.com

    • Unit-Tests und Integrationstests sind meiner Meinung nach eine sehr große Chance für PGlite.
      Projekte wie Drizzle ORM nutzen es bereits gut.
      Das Supabase-Team hat pg-gateway (https://github.com/supabase-community/pg-gateway) gebaut; damit kann jeder Postgres-Client eine Verbindung zu PGlite herstellen, was eine Möglichkeit für die Nutzung in CI sein könnte.
      Was ich gern erkunden würde, ist ein Copy-on-Write-VFS auf Seitenebene für PGlite.
      Wenn man PGlite mit einem geladenen Datensatz startet und die Datenbank dann für jeden Test sofort forken könnte, wären vermutlich Forks pro Test im Sub-Millisekundenbereich möglich, ohne die Komplexität von devcontainers oder Postgres-Template-Datenbanken.
    • Ich würde es auch gern in Go so verwenden.
      Aktuell nutzen wir in der Produktion postgres, dumpen aber für SQLite-basierte Integrationstests ein SQLite-kompatibles Schema.
      So bekommen wir Integrationstests unter einer Sekunde ohne Abhängigkeiten, während wir trotzdem eine echte Datenbank verwenden.
      Wenn wir Postgres direkt nutzen könnten, wäre das noch besser, weil wir dann auch Funktionen testen könnten, die PG-spezifische Features wie Volltextsuche benötigen.

  • PGlite / ElectricSQL ist eine Technologie, die ich in einem künftigen Job unbedingt ausprobieren möchte.
    Die Fähigkeit, Änderungen im Browser zu replizieren und zu abonnieren, wirkt enorm leistungsfähig.
    Ich habe früher Medizinsoftware gebaut, die Workloads für über zwei Millionen Patienten bewältigte und Nachfüllungen für Chemotherapie-, HIV- und immunbezogene Medikamente abwickelte; dabei kam es häufig vor, dass Leute während der Versicherungsbearbeitung oder Patiententelefonate gegenseitig ihre Arbeit überschrieben.
    Wegen IE7 mussten wir ein eigenes Locking-System bauen, das auf Interval-Funktionen und WebSockets beruhte, und während jemand einen Patienten anrief, konnte der Zuständige für finanzielle Unterstützung nicht am selben Profil arbeiten.
    Auch Volltextsuche oder Vektorsuche, die in großem Maßstab sehr teuer sind, ließen sich vielleicht lokal nutzen.

    • Das würde bedeuten, Patientendaten von zwei Millionen Menschen auf jedes Gerät zu laden.
      Für Medizinsoftware ist das eine sehr schlechte Wahl.

  • Ich frage mich, ob es davon eine ähnliche native Version gibt.
    Falls ich später eine native App bauen möchte, wäre mir eine Form lieber, bei der ich nicht die gesamte Architektur wegwerfen und neu anfangen muss.
    Auf der Website und in der Doku sehe ich nur die WASM-Version.

    • Ist geplant.
      Wir möchten die zentralen Änderungen extrahieren, die wir an Postgres vornehmen mussten, und daraus eine C-Bibliothek libpglite machen, die sich aus jeder Sprache/Plattform linken lässt.
      Für React Native ist diese Unterstützung wichtig, weil es dort keine WASM-Unterstützung gibt.

  • Dass es eine reaktive Live-Query-API gibt, ist sehr cool.
    Die meisten Beispiele für reaktive Queries sind sehr grundlegend, etwa einzelne Tabellen; ich frage mich, ob Live Queries auch Joins oder Aggregationen unterstützen.

    • Sollte alles funktionieren.
      Wir speichern die Query als View und schauen dann intern nach, von welchen Tabellen sie abhängt.
      Danach verwenden wir pg_notify, um Änderungen zu beobachten.
      Um das effizienter zu machen, planen wir die Integration von pg_ivm (https://github.com/sraoss/pg_ivm).