PGlite: WASM Postgres que se ejecuta dentro del navegador

 (pglite.dev)
2 puntos por GN⁺ 2024-08-13 | 1 comentarios | Compartir por WhatsApp
  • Permite ejecutar Postgres completo directamente en WASM para apps local-first y entornos de desarrollo basados en navegador, reduciendo la dependencia de servidores
  • Se ofrece como un build de menos de 3 MB con Gzip, en un formato fácil de embeber en navegadores y entornos locales
  • Mediante carga dinámica de extensiones, se pueden usar extensiones de Postgres como pgvector y PostGIS
  • Incluye primitivas integradas para carga de datos, sincronización y consultas en vivo, orientadas a apps reactivas y casos de uso en tiempo real
  • database.build de Supabase, basado en PGlite, ofrece una experiencia para crear y publicar bases de datos Postgres usando IA

Postgres para el navegador y entornos locales

  • PGlite es un Postgres embebido que ejecuta localmente una base de datos Postgres completa en WASM
  • Es un build completo de Postgres en WASM y se ofrece en menos de 3 MB comprimido con Gzip
  • Incluye primitivas integradas para carga de datos, sincronización y consultas en vivo, lo que permite construir flujos de datos reactivos centrados en el cliente

Extensiones y entorno de experimentación

  • Soporta un mecanismo de carga dinámica de extensiones
    • Incluye pgvector
    • También se puede usar PostGIS
  • En el Playground se pueden probar más extensiones
  • En la página actual se puede probar directamente PGlite Postgres completo ejecutándose dentro del navegador, con pgvector incluido

Documentación y canales de distribución

  • La documentación inicial está disponible en Get Started
  • GitHub muestra 15.5K estrellas
  • NPM muestra 10.1M descargas semanales

database.build de Supabase

  • database.build es un servicio creado por Supabase sobre PGlite
  • Ofrece un flujo para crear y publicar bases de datos Postgres con IA

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-08-13
Opiniones en Hacker News

  • Ya había visto que corría en el navegador y me pareció impresionante que fuera posible con una descarga de unos 3 MB, pero se me había pasado que también se ejecuta del lado del servidor en Node.js y Bun: https://pglite.dev/docs/
    Como no levanta un servidor de red real, se siente como una alternativa a SQLite, y me resulta interesante que se pueda iniciar directamente una implementación de PostgreSQL en proceso, persistida en disco, dentro de una app existente de Node.js/Bun
    También me gustaría probarlo en Python con wrappers como https://github.com/wasmerio/wasmer-python o https://github.com/bytecodealliance/wasmtime-py, y me pregunto si alguien ya ha ejecutado PGlite de esta manera

    • Hacer que PGlite funcione bien en otros lenguajes es una prioridad muy alta
      Estamos trabajando en dos enfoques: uno es un build WASI de API de bajo nivel que los usuarios puedan envolver con una API de alto nivel, y el otro es libpglite, que se puede enlazar desde lenguajes nativos
      La mayoría de los lenguajes ya tienen implementaciones del protocolo de cable de Postgres, así que envolver una API de bajo nivel que lo lea y lo emita es relativamente sencillo; el lado JS de PGlite funciona de la misma manera
    • Como solución temporal, parece viable llamar desde Python a un script de Node.js con subprocess para ejecutar exec y query de @electric-sql/pglite, e intercambiar los resultados como JSON
      La estructura sería crear una instancia de PGlite en db.js, recibir SQL y parámetros como argumentos de línea de comandos y procesarlos, y luego llamar desde main.py a node db.js exec ... o node db.js query ...
    • También quería probar PGlite en Python, y al leer este hilo me di cuenta de que ya es accesible desde Pyodide
      Pyodide es un port de CPython a Wasm y puede interactuar con objetos JavaScript mediante proxies
      Como ejemplo, creé globalThis.db = new PGlite() y luego desde código Python hice await a js.db.query() para ejecutar SELECT 'Hello, world!' AS "greeting";; actualmente funcionó en Node.js 18, Deno 1 y Bun 1
    • Me gustaría que alguien con más familiaridad con licencias explicara qué impacto tiene en proyectos comerciales o soluciones, y cómo se compara con algo como embedded FirebirdSQL
      Por ejemplo, me pregunto si se puede usar en un proyecto comercial sin publicar el código fuente, o si al embeberlo habría que cambiar la licencia para ajustarse a pg/fb
      Si lo necesitara de inmediato lo revisaría por mi cuenta, pero me da curiosidad porque los puntos de la simplicidad de SQLite que no me gustan se parecen bastante a las cosas que no me gustan de MySQL/MariaDB
    • Me intriga qué tan bien funcionará en la práctica
      No sé cómo modificaron la capa de persistencia de PostgreSQL, pero comparado con correr PostgreSQL en un contenedor Docker, parece que podría tener limitaciones
      SQLite no tiene esas limitaciones

  • Me gusta muchísimo PGlite
    Es una solución perfecta para tener Postgres sin Docker, y como permite crear una instancia de Postgres en la máquina local solo con npm install, hace muy fácil incorporar nuevos desarrolladores al equipo
    También funciona bien con Next.js, y lo estoy usando junto con Next.js Boilerplate en entornos locales y de desarrollo: https://github.com/ixartz/Next-js-Boilerplate
    Con un solo npm install queda lista una aplicación full-stack que incluye la base de datos, es decir, un Postgres funcionando, sin necesidad de instalar herramientas externas

    • Normalmente manejo las dependencias de desarrollo con docker compose, pero esto sin duda parece una alternativa genial

  • Para que la siguiente persona no tenga que buscarlo o preguntarlo: la persistencia del lado del navegador soporta IndexedDB y OPFS: <https://pglite.dev/docs/filesystems>

    • Tu trabajo y el de Roy sobre WASM SQLite VFS influyeron directamente en este trabajo

  • Apenas vi el título pensé: “esto encajaría muy bien con ElectricSQL”, y me alegra ver que en realidad viene del lado de ElectricSQL
    La experiencia inmediata para desarrolladores es excelente, y quiero probar PGlite y ElectricSQL en un proyecto de producción
    Siento que podría reducir varias molestias que estoy teniendo ahora, y personalmente también me gusta trabajar con CRDT

  • Felicitaciones por el Show HN
    Estaba mirando el servidor de Discord de ElectricSQL y me interesaba especialmente usarlo desde lenguajes que no fueran TypeScript, así que me alegra que estén priorizando la independencia del lenguaje
    Vi que ElectricSQL se estaba reescribiendo por un cambio de arquitectura, y me pregunto si eso afecta a PGlite o si ahora es un proyecto separado
    Además, SQLite en realidad es SQL-ite, es decir, de la familia de -ite, como urbanite, pero por reanálisis y libfixing parece que ahora la gente lo usa como si fuera el sufijo -lite
    Puede ser porque lite tiene un significado más claro, mientras que ite no tanto; es parecido a cómo helicopter originalmente era helic + opter, pero la gente lo interpretó como heli + copter, de donde salieron palabras como helipad o quadcopter
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite y Electric sync son proyectos separados, pero estamos haciendo que PGlite sea un destino de sincronización para Electric
      Los cambios del lado de Electric van en la dirección de pasar de una pila anterior fuertemente integrada a una pila acoplada de forma más flexible
      PGlite es uno de los posibles almacenes de cliente para Electric sync, y cubre casos de uso en los que se tiene una base de datos SQL completa en el cliente e incluso se puede usar el mismo esquema en el cliente y el servidor
      El nombre, por supuesto, es un homenaje a SQLite, y la l minúscula se incluyó para una ligera diferenciación y como guiño a “light”, además de transmitir la idea de un Postgres ligero

  • Normalmente habría dicho que la principal diferencia entre PostgreSQL y SQLite es que SQLite es en proceso, pero si ahora ambos pueden ser en proceso, me pregunto si hay algún material que los compare con más detalle
    ¿En qué situaciones conviene preferir uno sobre el otro?

    • SQLite está probadísimo desde hace muchísimo tiempo, pero con PGlite, después de tocarlo menos de 3 minutos, me encontré con un memory access out of bounds
      Aunque su hermano mayor PostgreSQL sea una de las bases de datos más robustas, puede que todavía sea difícil considerarlo listo para producción
      Claro que también he visto y sufrido problemas en SQLite, así que no existe el software sin bugs
    • Esta comparación realmente me interesa

  • Hace poco usé pglite para pruebas de integración de API en un proyecto paralelo y funcionó bastante bien
    La experiencia de desarrollo fue mucho mejor que usar algo como testcontainers[0] para levantar postgres en Docker
    [0]: https://testcontainers.com

    • Creo que las pruebas unitarias y de integración son una oportunidad enorme para PGlite
      Proyectos como Drizzle ORM ya lo están aprovechando bien
      El equipo de Supabase creó pg-gateway(https://github.com/supabase-community/pg-gateway), que permite conectarse a PGlite desde cualquier cliente de Postgres, y podría ser una forma de usarlo en CI
      Algo que quisiera explorar es un VFS a nivel de página con copia al escribir para PGlite
      Si se pudiera iniciar PGlite con un dataset cargado y luego bifurcar la base de datos instantáneamente para cada prueba, parecería posible tener forks por prueba en menos de un milisegundo, sin la complejidad de devcontainers ni de las bases de datos plantilla de Postgres
    • Quiero usarlo así también en Go
      Actualmente usamos postgres en producción, pero volcamos un esquema compatible con SQLite para pruebas de integración basadas en SQLite
      Gracias a eso podemos hacer pruebas de integración en menos de 1 segundo y sin dependencias, aun usando una base de datos real
      Si pudiéramos usar Postgres tal cual, sería aún mejor porque podríamos probar funciones que necesitan características exclusivas de PG, como la búsqueda de texto completo

  • PGlite / ElectricSQL es una tecnología que definitivamente quiero probar en un trabajo futuro
    La capacidad de replicar y suscribirse a cambios dentro del navegador se ve muy potente
    Antes desarrollé software médico que manejaba cargas de trabajo de más de 2 millones de pacientes y realizaba resurtidos de medicamentos relacionados con quimioterapia, VIH e inmunología, y era común que la gente se sobrescribiera el trabajo mutuamente durante procesos con aseguradoras o llamadas a pacientes
    Por IE7 tuvimos que crear nuestro propio sistema de bloqueo basado en una función de intervalos y WebSockets, y mientras alguien llamaba a un paciente, el responsable de asistencia financiera no podía trabajar en el mismo perfil
    También parece que búsquedas de texto completo o vectoriales, muy costosas a gran escala, podrían aprovecharse localmente

    • Eso significa poner los datos de 2 millones de pacientes en todos los dispositivos
      Para software médico, es una muy mala decisión

  • Me pregunto si existe una versión nativa parecida a esto
    Me gustaría que, si más adelante quiero crear una app nativa, no tenga que tirar toda la arquitectura y empezar de nuevo
    En el sitio web y la documentación solo veo la versión WASM

    • Está en los planes
      Queremos extraer los cambios principales que tuvimos que aplicar a Postgres y crear una biblioteca C libpglite que pueda enlazarse desde cualquier lenguaje/plataforma
      React Native no tiene soporte para WASM, así que este soporte es importante

  • Que haya una API de live query reactiva es genial
    La mayoría de los ejemplos de consultas reactivas son muy básicos, como una sola tabla, así que me pregunto si live query también admite joins o agregaciones

    • Todo debería funcionar
      La consulta se guarda como una vista y luego se inspecciona internamente de qué tablas depende
      Después se usa pg_notify para observar los cambios
      Para hacerlo más eficiente, planeamos integrar pg_ivm(https://github.com/sraoss/pg_ivm)