Postgres em WASM rodando no navegador: PGlite

 (pglite.dev)
2 pontos por GN⁺ 2024-08-13 | 1 comentários | Compartilhar no WhatsApp
  • Em apps local-first e ambientes de desenvolvimento baseados no navegador, é possível executar o Postgres completo diretamente em WASM, reduzindo a dependência de servidores
  • É oferecido em um build com menos de 3 MB em Gzip, o que facilita embutir em navegadores e ambientes locais
  • Por meio de carregamento dinâmico de extensões, é possível usar extensões do Postgres como pgvector e PostGIS
  • Inclui primitivas nativas para carregamento de dados, sincronização e live queries, sendo voltado para apps reativos e casos de uso em tempo real
  • O database.build da Supabase, baseado em PGlite, oferece uma experiência para criar e publicar bancos de dados Postgres com ajuda de IA

Postgres no navegador e localmente

  • PGlite é um Postgres embarcado que executa um banco de dados Postgres completo localmente em WASM
  • É um build WASM completo do Postgres e ainda assim é oferecido com menos de 3 MB em Gzip
  • Inclui primitivas nativas para carregamento de dados, sincronização e live queries, permitindo montar fluxos de dados reativos centrados no cliente

Extensões e ambiente de experimentação

  • Suporta um mecanismo de carregamento dinâmico de extensões
    • Inclui pgvector
    • Também é possível usar PostGIS
  • No Playground, é possível testar mais extensões
  • Nesta página, você pode experimentar imediatamente o PGlite Postgres completo rodando no navegador, incluindo pgvector

Documentação e canais de distribuição

  • Em Get Started, você pode conferir a documentação inicial
  • O GitHub mostra 15.5K estrelas
  • O NPM mostra 10.1M de downloads semanais

O database.build da Supabase

  • O database.build é um serviço criado pela Supabase com base no PGlite
  • Oferece um fluxo para criar e publicar bancos de dados Postgres com IA

Leituras relacionadas

1 comentários

 
GN⁺ 2024-08-13
Opiniões do Hacker News

  • Eu já tinha visto isso rodando no navegador e fiquei impressionado com o fato de ser possível com apenas cerca de 3 MB de download, mas não tinha percebido que também roda no lado servidor com Node.js e Bun: https://pglite.dev/docs/
    Como ele não sobe um servidor de rede de verdade, parece uma alternativa ao SQLite, e é interessante poder iniciar diretamente uma implementação de PostgreSQL in-process persistida em disco dentro de apps Node.js/Bun existentes
    Também gostaria de experimentar em Python usando wrappers como https://github.com/wasmerio/wasmer-python ou https://github.com/bytecodealliance/wasmtime-py, e fico curioso se alguém já rodou o PGlite dessa forma

    • Fazer o PGlite funcionar bem em outras linguagens é uma prioridade muito alta
      Estamos trabalhando em duas abordagens: uma é um build WASI de uma API de baixo nível que os usuários possam envolver com uma API de alto nível, e a outra é a libpglite, que pode ser linkada a partir de linguagens nativas
      Como a maioria das linguagens já tem implementações do protocolo wire do Postgres, envolver uma API de baixo nível que lê e emite isso é relativamente fácil, e o lado JS do PGlite funciona da mesma forma
    • Como paliativo, parece possível chamar um script Node.js a partir de Python com subprocess para executar exec e query do @electric-sql/pglite, trocando os resultados em JSON
      A estrutura seria criar uma instância do PGlite em db.js, receber SQL e parâmetros por argumentos de linha de comando, processar tudo e então chamar node db.js exec ... ou node db.js query ... a partir de main.py
    • Também gostaria de usar o PGlite em Python e, lendo esta thread, percebi que isso já é acessível no Pyodide
      O Pyodide é um port Wasm do CPython e consegue interagir com objetos JavaScript por meio de proxies
      No exemplo, foi criado globalThis.db = new PGlite() e, no código Python, foi feito await em js.db.query() para executar SELECT 'Hello, world!' AS "greeting";; atualmente funcionou no Node.js 18, Deno 1 e Bun 1
    • Seria bom se alguém mais familiarizado com licenças explicasse quais impactos isso teria em projetos comerciais ou soluções, e como se compara a algo como o FirebirdSQL embarcado
      Por exemplo, fico curioso se pode ser usado em um projeto comercial sem abrir o código-fonte, ou se ao embutir seria necessário mudar a licença para se adequar à do pg/fb
      Se eu precisasse disso agora, analisaria por conta própria, mas alguns pontos da simplicidade do SQLite que não me agradam são bem parecidos com coisas de que não gosto no MySQL/MariaDB, então fiquei curioso
    • É interessante ver quão bem isso vai funcionar na prática
      Não sei como eles modificaram a camada de persistência do PostgreSQL, mas, comparado a rodar PostgreSQL em um contêiner Docker, parece que pode haver limitações
      O SQLite não tem essas limitações

  • Gosto muito do PGlite
    É uma solução perfeita para ter Postgres sem Docker, e com apenas npm install é possível criar uma instância de Postgres na máquina local, o que torna muito fácil integrar novos desenvolvedores à equipe
    Também funciona bem com Next.js, e estamos usando em ambientes locais e de desenvolvimento junto com o Next.js Boilerplate: https://github.com/ixartz/Next-js-Boilerplate
    Com um único npm install, você tem uma aplicação full-stack incluindo o banco de dados, ou seja, um Postgres funcionando, sem precisar instalar ferramentas externas

    • Normalmente eu cuido das dependências de desenvolvimento com docker compose, mas isso definitivamente parece uma alternativa bacana

  • Para que a próxima pessoa não precise procurar ou perguntar: a persistência no lado do navegador oferece suporte a IndexedDB e OPFS: <https://pglite.dev/docs/filesystems>

    • O trabalho seu e do Roy no WASM SQLite VFS teve influência direta neste trabalho

  • Assim que vi o título, pensei “isso combinaria muito bem com o ElectricSQL”, então foi bom ver que veio justamente do pessoal da ElectricSQL
    A experiência imediata para desenvolvedores é excelente, e quero experimentar PGlite e ElectricSQL em um projeto em produção
    Parece que vai reduzir várias inconveniências que tenho hoje, e pessoalmente também gosto de trabalhar com CRDT

  • Parabéns pelo Show HN
    Eu estava acompanhando o servidor Discord do ElectricSQL e tinha interesse especial em usar em linguagens que não fossem TypeScript, então fico feliz em saber que a independência de linguagem está sendo priorizada
    Vi que o ElectricSQL estava sendo reescrito por causa de mudanças na arquitetura, e fiquei curioso para saber se isso afeta o PGlite ou se agora ele é um projeto separado
    Além disso, SQLite é na verdade SQL-ite, ou seja, da família -ite, como urbanite, mas por causa de reanálise e libfixing parece que hoje as pessoas usam como se fosse o sufixo -lite
    Talvez seja porque lite tem um significado mais claro, enquanto ite não; é parecido com helicopter, que originalmente era helic + opter, mas as pessoas passaram a interpretar como heli + copter, dando origem a palavras como helipad ou quadcopter
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite e Electric sync são projetos separados, mas estamos tornando o PGlite um destino de sincronização do Electric
      As mudanças no lado do Electric caminham de uma stack anterior fortemente integrada para uma stack acoplada de forma mais flexível
      O PGlite é um dos possíveis armazenamentos de cliente do Electric sync e atende ao caso de uso de ter um banco de dados SQL completo no cliente, podendo até usar o mesmo schema no cliente e no servidor
      O nome é, obviamente, uma homenagem ao SQLite; o l minúsculo entrou como uma pequena diferenciação e uma alusão a “light”, além de transmitir a ideia de um Postgres leve

  • Antes eu teria dito que a principal diferença entre PostgreSQL e SQLite é que o SQLite é in-process, mas agora, se ambos podem ser in-process, fico curioso se existe algum material comparando os dois em mais detalhes
    Em que situações deveríamos preferir um ao outro?

    • O SQLite é comprovado há muito, muito tempo, mas eu mexi no PGlite por nem 3 minutos e encontrei um memory access out of bounds
      Mesmo que seu irmão maior, o PostgreSQL, seja um dos bancos de dados mais robustos, talvez ainda seja difícil considerá-lo pronto para produção
      Claro, já vi e enfrentei problemas no SQLite também; software sem bugs não existe
    • Eu realmente gostaria de ver essa comparação

  • Usei o pglite recentemente em um projeto paralelo para testes de integração de API e funcionou muito bem
    A experiência de desenvolvimento foi muito melhor do que usar algo como testcontainers[0] para subir postgres no Docker
    [0]: https://testcontainers.com

    • Vejo testes unitários e de integração como uma oportunidade enorme para o PGlite
      Projetos como o Drizzle ORM já estão tirando bom proveito disso
      A equipe da Supabase criou o pg-gateway(https://github.com/supabase-community/pg-gateway), que permite conectar ao PGlite a partir de qualquer cliente Postgres, podendo ser uma forma de usá-lo em CI
      Algo que eu gostaria de explorar é um VFS em nível de página com copy-on-write para o PGlite
      Se fosse possível iniciar um PGlite com um dataset carregado e então fazer fork imediato do banco de dados para cada teste, daria para ter forks por teste em menos de um milissegundo, sem a complexidade de devcontainers ou de bancos de dados template do Postgres
    • Quero usar algo assim também em Go
      Hoje usamos postgres em produção, mas geramos um dump de um schema compatível com SQLite para testes de integração baseados em SQLite
      Com isso, conseguimos testes de integração em menos de 1 segundo, sem dependências, ainda usando um banco de dados real
      Se fosse possível usar Postgres diretamente, seria ainda melhor, porque poderíamos testar recursos que exigem funcionalidades específicas do PG, como busca full-text

  • PGlite / ElectricSQL é uma tecnologia que eu definitivamente quero usar em um futuro emprego
    A capacidade de replicar e assinar mudanças dentro do navegador parece extremamente poderosa
    No passado, criei software médico que processava uma carga de trabalho de mais de 2 milhões de pacientes, fazendo reabastecimento de medicamentos de quimioterapia/HIV/imunológicos, e era comum as pessoas sobrescreverem o trabalho umas das outras durante processamento de seguros ou chamadas com pacientes
    Por causa do IE7, tivemos de criar nosso próprio sistema de bloqueio baseado em uma função de interval e websockets; enquanto alguém ligava para um paciente, o responsável por assistência financeira não podia trabalhar no mesmo perfil
    Também parece possível aproveitar localmente busca full-text ou busca vetorial, que em grande escala têm custo muito alto

    • Isso significa colocar os dados de 2 milhões de pacientes em todos os dispositivos
      Para software médico, é uma péssima escolha

  • Fico curioso se existe uma versão nativa semelhante a isso
    Gostaria que, se no futuro eu quisesse criar um app nativo, não precisasse jogar fora toda a arquitetura e recomeçar
    No site e na documentação, só vejo a versão WASM

    • Está nos planos
      Queremos extrair as mudanças centrais que tivemos de aplicar ao Postgres e criar uma biblioteca C libpglite que possa ser vinculada em qualquer linguagem/plataforma
      Como o React Native não tem suporte a WASM, esse suporte é importante

  • É muito legal ver uma live query API reativa
    A maioria dos exemplos de consultas reativas é bem básica, como uma única tabela; fiquei curioso se live query também dá suporte a joins ou agregações

    • Tudo isso deve funcionar
      Salvamos a consulta como uma view e então inspecionamos internamente para ver de quais tabelas ela depende
      Depois usamos pg_notify para monitorar mudanças
      Para tornar isso mais eficiente, planejamos integrar o pg_ivm(https://github.com/sraoss/pg_ivm)