PGlite、Postgresをブラウザ内へ持ち込むlocal-first databaseの設計

Kyle Mathewsは、Postgresをブラウザ内で扱えるlocal-firstの道をPGliteとして示した。出典

ブラウザにPostgresを持ち込む

PGliteはPostgresをWebAssemblyとして配布し、browserやNode.jsプロセスで動かす。出典

互換性を入口にする

新しいdatabase APIを覚えさせるのではなく、SQLとPostgresの知識を持つ開発者が試せる設計にした。出典

local-firstへの接続

ElectricのdocsはPGliteを同期やlocal-firstアプリの構成要素として説明している。出典

まだ残る設計課題

容量、永続化、同期、競合解決はアプリごとに判断が必要だ。

PGliteはserver databaseを置き換える魔法ではなく、client側の選択肢を増やす道具である。

今の示唆

既存の標準を捨てずに実行場所だけを変えると、新しいUXへの移行摩擦を下げられる。

PGliteはPostgresのSQLと拡張性を、browser内のlocal-first体験へ持ち込みたい開発者に刺さる。

既存DBの知識を捨てずにofflineや高速なUIを試せる点が導入理由になる。出典

PostgresをWebAssemblyへ落とし込む実装知識と、Electricの同期基盤との接続が障壁になる。出典

ネットワーク効果は弱い。

利用者増加による直接価値より、Postgres拡張・サンプル・統合知見の蓄積が間接的なecosystem効果になる。

local-first、offline、browser内検索を必要とするTypeScript開発チーム。

単純なCRUDをサーバーだけで完結できる案件には過剰。

Postgres互換性、WebAssemblyによる配布、TypeScriptから扱えるAPIの組み合わせが強い。

OSSなので実装を検証しながら採用できる。出典

browser内DBは容量、同期、永続化、競合解決を利用者側で設計する必要がある。

大規模なserver-authoritative処理には適合性を要確認とする。

docs、GitHub、技術ブログでPostgres開発者を獲得し、PGlite単体からElectricのsyncへ導く。

既存のSQL資産を入口にすることで学習コストを抑える。出典

主要チャネル: content, github, community, partnerships

新しい実行環境を広げるとき、既存開発者が慣れたSQLとPostgres互換性を入口にする設計は強い。

日本では現場端末の一時オフライン、教育用データアプリ、業務入力の下書きに接点がある。

同期と認証の実装例を日本語で揃えることが導入の鍵になる。