PGlite, Postgres en WASM qui s’exécute dans le navigateur

 (pglite.dev)
2 points par GN⁺ 2024-08-13 | 1 commentaires | Partager sur WhatsApp
  • Dans les apps local-first et les environnements de développement basés sur le navigateur, il permet d’exécuter Postgres complet directement en WASM, ce qui réduit la dépendance aux serveurs
  • Proposé sous la forme d’un build de moins de 3 Mo une fois compressé avec Gzip, facile à embarquer dans le navigateur et en local
  • Grâce au chargement dynamique d’extensions, il permet d’utiliser des extensions Postgres comme pgvector et PostGIS
  • Il intègre le chargement de données, la synchronisation et des primitives de live query, ce qui le rend adapté aux apps réactives et aux cas d’usage en temps réel
  • Le service database.build de Supabase, basé sur PGlite, offre une expérience permettant de créer et publier des bases de données Postgres avec l’aide de l’IA

Postgres pour le navigateur et le local

  • PGlite est un Postgres embarqué qui exécute localement une base de données Postgres complète en WASM
  • C’est un build WASM complet de Postgres, proposé en moins de 3 Mo une fois compressé avec Gzip
  • Il intègre le chargement de données, la synchronisation et des primitives de live query, ce qui permet de mettre en place des flux de données réactifs centrés sur le client

Extensions et environnement d’expérimentation

  • Il prend en charge un mécanisme de chargement dynamique d’extensions
    • Inclut pgvector
    • PostGIS peut aussi être utilisé
  • Vous pouvez tester davantage d’extensions dans le Playground
  • Sur la page actuelle, vous pouvez essayer immédiatement PGlite Postgres complet exécuté dans le navigateur, avec pgvector inclus

Documentation et canaux de distribution

  • Vous pouvez consulter la documentation de démarrage dans Get Started
  • Le GitHub affiche 15,5 K étoiles
  • Le NPM affiche 10,1 M de téléchargements hebdomadaires

database.build de Supabase

  • database.build est un service créé par Supabase sur la base de PGlite
  • Il propose un parcours pour créer et publier une base de données Postgres avec l’IA

À lire aussi

1 commentaires

 
GN⁺ 2024-08-13
Commentaires sur Hacker News

  • J’avais déjà vu que ça tournait dans le navigateur, et le fait que ce soit possible avec à peine 3 Mo de téléchargement m’avait impressionné, mais j’étais passé à côté du fait que cela fonctionne aussi côté serveur avec Node.js et Bun : https://pglite.dev/docs/
    Comme il ne s’agit pas de lancer un vrai serveur réseau, ça donne l’impression d’une alternative à SQLite, et je trouve intéressant de pouvoir démarrer directement une implémentation in-process de PostgreSQL avec persistance sur disque dans une application Node.js/Bun existante
    J’aimerais aussi l’essayer en Python avec des wrappers comme https://github.com/wasmerio/wasmer-python ou https://github.com/bytecodealliance/wasmtime-py, et je me demande si quelqu’un a déjà fait tourner PGlite de cette manière

    • Faire en sorte que PGlite fonctionne bien dans d’autres langages est une priorité très élevée
      Nous travaillons sur deux approches : l’une est une version WASI d’une API bas niveau que les utilisateurs peuvent envelopper dans une API de plus haut niveau, et l’autre est libpglite, qui peut être liée depuis des langages natifs
      La plupart des langages ont déjà une implémentation du protocole wire de Postgres, donc envelopper une API bas niveau qui lit et émet ce protocole est relativement simple, et c’est aussi ainsi que fonctionne la partie JS de PGlite
    • Comme solution provisoire, il semble possible en Python d’appeler un script Node.js via subprocess pour exécuter exec et query de @electric-sql/pglite, puis d’échanger les résultats en JSON
      La structure consiste à créer une instance PGlite dans db.js, à recevoir le SQL et les paramètres via les arguments de ligne de commande, puis à appeler dans main.py node db.js exec ... ou node db.js query ...
    • J’aimerais aussi essayer PGlite en Python, et en lisant ce fil je viens de réaliser qu’il est déjà accessible dans Pyodide
      Pyodide est un port Wasm de CPython et permet d’interagir avec des objets JavaScript via des proxys
      Dans l’exemple, on crée globalThis.db = new PGlite(), puis on fait un await sur js.db.query() dans du code Python pour exécuter SELECT 'Hello, world!' AS "greeting";, et cela fonctionne actuellement sur Node.js 18, Deno 1 et Bun 1
    • Ce serait bien que quelqu’un de plus à l’aise avec les licences explique quelles seraient les implications pour des projets commerciaux ou des solutions de ce type, et comment cela se compare à quelque chose comme FirebirdSQL embarqué
      Par exemple, je me demande si on peut l’utiliser dans un projet commercial sans publier le code source, ou si l’embarquer oblige à adapter la licence en fonction de pg/fb
      Si j’en ai besoin tout de suite, je regarderai moi-même, mais certains aspects de la simplicité de SQLite qui me gênent ressemblent beaucoup à ce que je n’aime pas dans MySQL/MariaDB, donc ça m’intrigue
    • Je suis curieux de voir à quel point cela fonctionne bien en pratique
      Je ne sais pas comment la couche de persistance de PostgreSQL a été modifiée, mais par rapport à l’exécution de PostgreSQL dans un conteneur Docker, il semble possible qu’il y ait des limites
      SQLite n’a pas ce genre de contraintes

  • J’aime vraiment beaucoup PGlite
    C’est la solution parfaite pour disposer de Postgres sans Docker, et le simple npm install permet de créer une instance Postgres sur une machine locale, ce qui rend l’onboarding de nouveaux développeurs dans l’équipe très simple
    Cela fonctionne aussi très bien avec Next.js, et je l’utilise avec un boilerplate Next.js en local et en environnement de développement : https://github.com/ixartz/Next-js-Boilerplate
    Avec un seul npm install, on obtient une application full stack avec la base de données incluse, c’est-à-dire un Postgres fonctionnel, sans avoir à installer d’outils externes

    • D’habitude, je gère les dépendances de développement avec docker compose, mais ça ressemble clairement à une alternative très élégante

  • Pour éviter que la personne suivante ait à le chercher ou à poser la question : la persistance côté navigateur prend en charge IndexedDB et OPFS : <https://pglite.dev/docs/filesystems>

    • Votre travail à toi et Roy sur le VFS SQLite en WASM a eu une influence directe sur ce travail

  • En voyant le titre, ma première pensée a été : « ça irait vraiment très bien avec ElectricSQL », donc c’est agréable de voir que cela vient effectivement d’ElectricSQL
    L’expérience développeur immédiate est excellente, et j’aimerais essayer PGlite et ElectricSQL dans un projet de production
    J’ai l’impression que cela réduirait plusieurs irritants que je rencontre actuellement, et personnellement j’aime aussi travailler avec les CRDT

  • Félicitations pour le Show HN
    Je suivais le serveur Discord d’ElectricSQL et j’étais particulièrement intéressé par son usage depuis d’autres langages que TypeScript, donc je suis ravi d’apprendre que l’indépendance vis-à-vis du langage est une priorité
    J’avais vu qu’ElectricSQL était en cours de réécriture à cause d’un changement d’architecture, et je me demande si cela affecte PGlite, ou si c’est désormais un projet séparé
    Et puis SQLite est en réalité SQL-ite, c’est-à-dire de la famille des -ite comme urbanite, mais à cause de la réanalyse et de la libfixation, on dirait que les gens l’emploient maintenant comme si c’était le suffixe -lite
    C’est peut-être parce que lite a un sens plus clair alors que ite n’en a pas, un peu comme helicopter était à l’origine helic + opter, mais que les gens l’ont compris comme heli + copter, ce qui a donné des mots comme helipad ou quadcopter
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite et Electric sync sont des projets distincts, mais nous faisons de PGlite une cible de synchronisation pour Electric
      Les changements côté Electric vont dans le sens d’une pile plus faiblement couplée, au lieu de l’ancienne pile très intégrée
      PGlite est l’un des stockages client possibles pour Electric sync, et répond à des cas d’usage où l’on veut une base SQL complète côté client, avec éventuellement le même schéma sur le client et le serveur
      Le nom est évidemment un hommage à SQLite, et le l minuscule sert à se distinguer légèrement tout en suggérant “light”, avec aussi l’idée d’un Postgres léger

  • Avant, j’aurais dit que la principale différence entre PostgreSQL et SQLite était que SQLite est in-process, mais si les deux peuvent désormais l’être, je me demande s’il existe une comparaison plus détaillée entre eux
    Dans quels cas faudrait-il préférer l’un à l’autre ?

    • SQLite a vraiment fait ses preuves depuis très longtemps, mais avec moins de trois minutes d’essai de PGlite, je suis déjà tombé sur memory access out of bounds
      Même si son grand frère PostgreSQL est l’une des bases de données les plus robustes qui soient, il est peut-être encore trop tôt pour le considérer prêt pour la production
      Cela dit, j’ai aussi vu et rencontré des problèmes avec SQLite, donc il n’existe pas de logiciel sans bug
    • C’est vraiment une comparaison que j’aimerais voir

  • J’ai récemment utilisé pglite pour des tests d’intégration d’API dans un side project, et ça a plutôt bien marché
    L’expérience développeur était bien meilleure que d’utiliser quelque chose comme testcontainers[0] pour lancer postgres dans Docker
    [0]: https://testcontainers.com

    • Je pense que les tests unitaires et les tests d’intégration représentent une très grosse opportunité pour PGlite
      Des projets comme Drizzle ORM en tirent déjà bien parti
      L’équipe Supabase a créé pg-gateway(https://github.com/supabase-community/pg-gateway), ce qui permet de se connecter à PGlite depuis n’importe quel client Postgres, et cela pourrait en faire une solution utilisable en CI
      Ce que j’aimerais explorer, c’est un VFS au niveau page avec copy-on-write pour PGlite
      Si l’on pouvait démarrer PGlite avec un jeu de données chargé, puis fork instantanément la base pour chaque test, on pourrait avoir des forks en moins d’une milliseconde par test, sans la complexité des devcontainers ou des bases de données modèles de Postgres
    • J’aimerais aussi utiliser quelque chose comme ça en Go
      Aujourd’hui, en production, nous utilisons postgres, mais nous exportons un schéma compatible SQLite pour des tests d’intégration basés sur SQLite
      Cela nous permet d’avoir des tests d’intégration en moins d’une seconde, sans dépendances, tout en utilisant une vraie base de données
      Si nous pouvions utiliser Postgres tel quel, ce serait encore mieux, car nous pourrions aussi tester les fonctionnalités qui nécessitent des fonctionnalités spécifiques à PG comme la recherche plein texte

  • PGlite / ElectricSQL est une technologie que j’aimerais vraiment utiliser dans un futur poste
    La capacité à répliquer et à s’abonner aux changements dans le navigateur paraît extrêmement puissante
    J’ai déjà développé un logiciel médical qui gérait la charge de travail de plus de 2 millions de patients, avec renouvellement de traitements liés à la chimiothérapie, au VIH et à l’immunologie, et il arrivait souvent que des personnes se marchent dessus pendant le traitement des assurances ou lors des appels avec les patients
    À cause d’IE7, nous avions dû construire notre propre système de verrouillage basé sur des fonctions d’intervalle et des websockets, et pendant qu’une personne appelait un patient, le responsable de l’aide financière ne pouvait pas travailler sur le même profil
    Il semble aussi possible d’exploiter localement la recherche plein texte ou la recherche vectorielle, qui coûtent très cher à grande échelle

    • Cela voudrait dire mettre les données de 2 millions de patients sur tous les appareils
      C’est un très mauvais choix pour un logiciel médical

  • Je me demande s’il existe une version native de quelque chose de similaire
    J’aimerais que ce soit un modèle qui m’évite de devoir jeter toute l’architecture et repartir de zéro si, plus tard, je veux créer une application native
    Sur le site et dans la documentation, je ne vois que la version WASM

    • C’est prévu
      Nous voulons extraire les changements fondamentaux qu’il a fallu apporter à Postgres afin de créer une bibliothèque C libpglite que l’on pourrait lier depuis n’importe quel langage ou plateforme
      React Native n’a pas de support WASM, donc cette prise en charge est importante

  • Avoir une live query API réactive, c’est vraiment génial
    La plupart des exemples de requêtes réactives sont très basiques, comme sur une seule table, donc je me demande si les live queries prennent aussi en charge les jointures ou les agrégations

    • Tout devrait fonctionner
      Nous stockons la requête comme une vue, puis nous inspectons en interne de quelles tables elle dépend
      Ensuite, nous surveillons les changements avec pg_notify
      Pour rendre cela plus efficace, nous prévoyons d’intégrer pg_ivm(https://github.com/sraoss/pg_ivm)