ブラウザ内で動作するWASM Postgres、PGlite

 (pglite.dev)
2 ポイント 投稿者 GN⁺ 2024-08-13 | 1件のコメント | WhatsAppで共有
  • ローカルファーストアプリやブラウザベースの開発環境で、完全なPostgresをWASMとして直接実行でき、サーバー依存を減らせる
  • Gzip基準で3MB未満のビルドとして提供され、ブラウザやローカル環境に組み込みやすい形になっている
  • 動的拡張ロードにより、pgvectorやPostGISのようなPostgres拡張を利用できる
  • データ読み込み、同期、ライブクエリプリミティブを内蔵し、リアクティブなアプリやリアルタイム用途に適している
  • Supabaseのdatabase.buildはPGliteベースで、AIを活用してPostgresデータベースを作成・公開する体験を提供する

ブラウザとローカルで使うPostgres

  • PGliteは、WASM上で完全なPostgresデータベースをローカル実行する組み込み型Postgres
  • 完全なPostgres WASMビルドでありながら、Gzip圧縮基準で3MB未満として提供される
  • データ読み込み、同期、ライブクエリプリミティブを内蔵し、クライアント中心のリアクティブなデータフローを構成できる

拡張と実験環境

  • 動的拡張ロードメカニズムをサポートする
    • pgvectorを含む
    • PostGISも利用できる
  • Playgroundでさらに多くの拡張を試せる
  • 現在のページで、ブラウザ内で動作する完全なPGlite Postgresをすぐに試せ、pgvectorも含まれる

ドキュメントと配布チャネル

  • Get Startedで入門ドキュメントを確認できる
  • GitHubではスター15.5Kを表示している
  • NPMでは週間ダウンロード数10.1Mを表示している

Supabaseのdatabase.build

  • database.buildは、SupabaseがPGliteベースで作ったサービス
  • AIでPostgresデータベースを生成し公開できるフローを提供する

関連記事

1件のコメント

 
GN⁺ 2024-08-13
Hacker Newsのコメント

  • 以前、ブラウザで動くものは見たことがあり、約3MBのダウンロードだけで可能だという点が印象的だったが、Node.jsとBunのサーバー側でも実行できることは見落としていた: https://pglite.dev/docs/
    実際のネットワークサーバーを立てるわけではないのでSQLiteの代替のように感じられ、既存のNode.js/Bunアプリ内で、ディスクに永続化されるインプロセスPostgreSQL実装をすぐ起動できる点が興味深い
    Pythonでも https://github.com/wasmerio/wasmer-python や https://github.com/bytecodealliance/wasmtime-py のようなラッパーで使ってみたいが、すでにPGliteをこの方法で動かした人がいるのか気になる

    • PGliteを他の言語でうまく動作させることは、非常に優先度が高い
      2つのアプローチを進めていて、1つはユーザーが高水準APIでラップできる低水準APIのWASIビルド、もう1つはネイティブ言語からリンクできるlibpglite
      ほとんどの言語にはすでにPostgresワイヤープロトコル実装があるので、それを読み書きする低水準APIをラップするのは比較的簡単で、PGliteのJS側も同じ方式で動作する
    • 当座の回避策としては、PythonからsubprocessでNode.jsスクリプトを呼び出して@electric-sql/pgliteのexecとqueryを実行し、結果をJSONでやり取りする形が可能そう
      db.jsでPGliteインスタンスを作り、コマンドライン引数としてSQLとパラメータを受け取って処理し、main.pyからnode db.js exec ...またはnode db.js query ...を呼び出す構成
    • PythonでもPGliteを使ってみたく、このスレッドを読んでいてPyodideではすでにアクセス可能だと気づいた
      PyodideはCPythonのWasmポートで、プロキシを通じてJavaScriptオブジェクトと相互作用できる
      例としてglobalThis.db = new PGlite()を作ったうえで、Pythonコードからjs.db.query()をawaitしてSELECT 'Hello, world!' AS "greeting";を実行しており、現在Node.js 18、Deno 1、Bun 1で動作した
    • ライセンスにもっと詳しい人が、商用プロジェクトやソリューションにどんな影響があるのか、embedded FirebirdSQLのようなものとどう比較されるのか説明してくれるとありがたい
      たとえば、ソース公開なしで商用プロジェクトに使えるのか、組み込むとライセンスをpg/fbに合わせて変えなければならないのかが気になる
      今すぐ必要なら自分で確認するが、SQLiteの単純さで気に入らない点が、MySQL/MariaDBで嫌いな点とかなり似ているので興味が湧いた
    • 実際にどれくらいうまく動くのか興味深い
      PostgreSQLの永続化レイヤーをどう修正したのかは分からないが、DockerコンテナでPostgreSQLを動かす場合と比べると制限があるかもしれない
      SQLiteにはそうした制限はない

  • PGliteは本当に気に入っている
    DockerなしでPostgresを用意できる完璧な解決策で、npm installだけでローカルマシンにPostgresインスタンスを作れるため、新しい開発者をチームにオンボーディングするのがとても簡単になる
    Next.jsとも相性がよく、ローカルおよび開発環境でNext.js Boilerplateと一緒に使っている: https://github.com/ixartz/Next-js-Boilerplate
    npm install一回で、データベースまで含んだフルスタックアプリケーション、つまり動作するPostgresが用意され、外部ツールのインストールは不要

    • 通常、開発依存関係はdocker composeで扱うが、これは確かに素晴らしい代替案に見える

  • 次の人が自分で探したり質問したりしなくて済むように残しておくと、ブラウザ側の永続化はIndexedDBとOPFSをサポートしている: <https://pglite.dev/docs/filesystems>

    • WASM SQLite VFSに関するあなたとRoyの作業が、この作業に直接影響を与えた

  • タイトルを見た瞬間に「これはElectricSQLと本当に相性がよさそうだ」と思ったが、実際にElectricSQL側から出てきたものだと知ってよかった
    即時性のある開発者体験が素晴らしく、PGliteとElectricSQLを本番プロジェクトで使ってみたい
    今抱えているいろいろな不便を減らしてくれそうで、個人的にはCRDTで作業するのも好き

  • Show HN おめでとう
    ElectricSQL の Discord サーバーを見ていて、TypeScript 以外の言語で使うことに特に関心があったので、言語非依存性を優先していると聞いてうれしい
    ElectricSQL はアーキテクチャ変更のために書き直されていると見たが、それが PGlite に影響するのか、それとも今は別プロジェクトなのか気になる
    それと SQLite は実は SQL-ite、つまり urbanite のような -ite 系なのに、再分析と libfixing のせいで、今では人々が -lite 接尾辞のように使っているようだ
    lite のほうが意味がはっきりしている一方で ite はそうではないからかもしれず、helicopter が元々 helic + opter だったのに、人々が heli + copter と受け取り、helipad や quadcopter のような語が生まれたのと似ている
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite と Electric sync は別プロジェクトだが、PGlite を Electric の同期対象にしようとしている
      Electric 側の変更は、以前の強く統合されたスタックから、より疎結合なスタックへ向かうもの
      PGlite は Electric sync のクライアントストア候補の一つで、クライアントに完全な SQL データベースを置き、クライアントとサーバーで同じスキーマを使うこともできるユースケースを満たす
      名前はもちろん SQLite へのオマージュで、小文字の l は少しの差別化と “light” への含みとして入れており、軽量な Postgres という意味も込めている

  • 以前なら PostgreSQL と SQLite の主な違いは SQLite が インプロセスである点だと言ったと思うが、今やどちらもインプロセスで可能なら、両者をより詳しく比較した資料があるのか気になる
    どんな状況で一方をもう一方より選ぶべきだろうか？

    • SQLite は本当に長い間実証されてきたが、PGlite は 3 分も触らないうちに memory access out of bounds に遭遇した
      兄貴分の PostgreSQL が最も堅牢なデータベースの一つだとしても、まだ本番環境向けの準備ができているとは言いにくいかもしれない
      もちろん SQLite でも問題を見たことも経験したこともあるので、バグのないソフトウェアはない
    • この比較は本当に知りたい

  • 最近のサイドプロジェクトで API 統合テストに pglite を使ってみたが、かなりうまく動いた
    Docker で postgres を立ち上げるために testcontainers[0] のようなものを使うより、開発者体験がはるかによかった
    [0]: https://testcontainers.com

    • ユニットテストと統合テストは PGlite にとって非常に大きなチャンスだと思う
      Drizzle ORM のようなプロジェクトはすでにうまく活用している
      Supabase チームが pg-gateway(https://github.com/supabase-community/pg-gateway) を作っており、これによって任意の Postgres クライアントから PGlite に接続できるので、CI で使う方法になり得る
      探ってみたいのは、PGlite 用の コピーオンライトのページレベル VFS だ
      データセットを入れた PGlite を起動したあと、各テストごとにデータベースを即座にフォークできるなら、devcontainers や Postgres のテンプレートデータベースの複雑さなしに、テストごとにミリ秒未満のフォークが可能になりそうだ
    • Go でもこういう使い方をしたい
      今は本番では postgres を使っているが、SQLite ベースの統合テストのために SQLite 互換スキーマをダンプしている
      そのおかげで実際のデータベースを使いながら、依存関係なしで 1 秒未満の統合テストが可能になっている
      Postgres をそのまま使えるなら、全文検索のような PG 専用機能が必要な機能もテストできるのでさらによい

  • PGlite / ElectricSQL は、将来の職場でぜひ使ってみたい技術だ
    ブラウザ内で変更を複製し、購読できる能力は非常に強力に見える
    以前、200 万人を超える患者のワークロードを処理し、化学療法/HIV/免疫関連の薬のリフィルを行う 医療ソフトウェアを作っていたが、保険処理や患者との通話中に互いの作業を上書きしてしまうことがよくあった
    IE7 のせいで interval 関数と WebSocket に依存する独自のロックシステムを作る必要があり、誰かが患者に電話している間、財務支援担当者は同じプロフィールで作業できなかった
    大規模ではコストが非常に高い全文検索やベクトル検索も、ローカルで活用できそうだ

    • それは 200 万人分の患者データをすべての端末に載せるという意味だ
      医療ソフトウェアとしては非常に悪い選択だ

  • これに似た ネイティブ版があるのか気になる
    後でネイティブアプリを作りたくなったときに、アーキテクチャを丸ごと捨ててやり直さなくてもよい形だとうれしい
    Web サイトとドキュメントでは WASM 版しか見当たらない

    • 計画されている
      Postgres に適用する必要があった中核的な変更を抽出して、どんな言語/プラットフォームからでもリンクできる libpglite C ライブラリを作りたい
      React Native は WASM をサポートしていないので、この対応は重要だ

  • リアクティブな live query API があるなんて、とてもいい
    リアクティブクエリの例のほとんどは単一テーブルのような非常に基本的なものだが、live query が JOIN や集計もサポートするのか気になる

    • すべて動作するはず
      クエリをビューとして保存したあと、どのテーブルに依存しているか内部を調べる
      その後 pg_notify を使って変更を監視する
      より効率的にするために pg_ivm(https://github.com/sraoss/pg_ivm) を統合する計画だ