Electric、Postgresの変更をローカルへ流す同期エンジンに賭けた設計

Postgresを捨てずにlocal-firstへ

Electricの創業者Kyle Mathewsは、Postgresをsource of truthに保ったままクライアントをリアクティブにする道を選んだ。

公式の説明では、Electric SyncはPostgresからShapeをHTTPで同期するread-path sync engineである。出典

調査から同期プリミティブへ

初期のElectricはlocal-firstと分散データの難しさを、Rich-CRDTsやstate transferの研究的な記事として掘り下げた。出典

転機はShapeだった

やがて、複雑な同期をShapeという小さなプリミティブに落とし、HTTP APIと既存frontendへ接続する製品の輪郭が明確になった。

QuickstartではPostgresの変更が複数のユーザーやデバイスへリアルタイムに反映される流れを示している。出典

syncからagentへ

2026年にはElectric Agentsを発表し、同期されたデータ層をlong-lived agentの基盤へ広げた。出典

Kyle Mathewsが選んだのは、別の巨大なAI runtimeを作ることではなく、データの同期という得意領域から用途を拡張する道だった。

今の示唆

Electricの歩みは、既存DBとの互換性を守ることが成長戦略になり得る例だ。

local-firstやagentという大きな言葉より、ShapeとHTTPという小さな接続点を先に実装したことが、次の用途へ進む余地を作ったと言える。

ElectricはPostgresを既存のsource of truthとして残したまま、クライアント側の反応性とoffline耐性を欲しい開発チームに刺さる。

Shapeというread-pathの抽象化で、同期対象をHTTPで扱えるため、専用backendへの全面移行を迫らない。出典

ShapeとPostgresの変更ストリームを実運用で磨く技術知識、OSSコミュニティ、PGliteやDurable Streamsまで広がる周辺資産が障壁になる。

ただしプロトコル自体はopenで、lock-inを避ける姿勢が差別化でもある。出典

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

利用者が増えても同期プロトコルの価値は直接増えないが、統合例・client実装・デバッグ知見が蓄積し、間接的なecosystem効果は期待できる。

Postgresを中心に据えたSaaS、collaborative app、offline対応が必要なプロダクトの少人数開発チーム。

単純なCRUDや厳密なserver-authoritative設計だけで足りるチームには過剰。

Postgres互換性、HTTP/JSONという理解しやすい境界、OSSによる検証可能性の組み合わせが強い。

TanStack DBやReactなど既存のfrontend文脈へ接続し、技術の新しさではなく導入経路を売っている。出典

同期はデータ設計・認証・書き戻しの責務を消さない。

高頻度更新、大規模なShape、接続断の競合解決では設計と運用の複雑さが残る。

Managed Cloudの価格やSLAも公開情報だけでは要確認。

OSSのdocsとGitHubで開発者を獲得し、QuickstartからCloudへ導く。

local-firstの実装課題をTanStack DBなどの既存コミュニティで解き、さらにagentという新しい用途へ拡張する戦略だ。出典

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

新しい開発体験を広げるとき、既存DBを捨てさせずread pathから導入できる設計は強い。

抽象化の価値は機能数ではなく、既存の責務分担を壊さずに複雑さを移動できるかで決まる。

日本では業務アプリのoffline・現場同期・複数拠点運用に接点がある。

まずPostgresを使う受託開発やSaaSの共通部品として、認証と書き戻しの実装パターンまで日本語化すると導入障壁を下げられる。