DoltgresはPostgreSQLの表を履歴付きで扱うベータデータベース

テーブルをGitのように扱う発想

DoltgresはDoltのストレージとSQLエンジンを土台にしたPostgres風データベースです。通常のPostgres接続でスキーマとデータを読み書きしつつ、テーブルをブランチ、マージ、フォーク、クローン、プッシュ、プルの単位として扱えます。バージョン管理の操作面はGit風CLIではなく、システムテーブル、関数、プロシージャとしてSQLに現れます。

この設計は、分析用データの変更を試し、差分を確認してから共有したい場面で意味があります。一方、PostgreSQLの接続互換性だけで全機能互換を期待するものではありません。README自身がベータ品質と説明しており、採用判断はアプリケーションのSQL表面に左右されます。

最初の起動で確認する設定

LinuxまたはmacOSではリリースのinstall.sh、WindowsではMSI、コンテナではdolthub/doltgresqlイメージを使えます。Dockerの例はDOLTGRES_PASSWORDを渡して5432番ポートを公開します。ソースからは./scripts/build.shでバイナリを作ります。初回起動時はpostgresユーザーとpostgresデータベースが作られ、データディレクトリはconfig.yamlまたはDOLTGRES_DATA_DIRで変更できます。

検証環境では初期パスワードを残さず、DOLTGRES_USERとDOLTGRES_PASSWORDを初回起動前に設定します。psqlで接続できたら、getting_startedデータベースにemployees、teams、employees_teamsを作成し、主キーと外部キーが受け入れられるかを確認すると、接続だけでなく基本DDLまで見られます。

SQLで記録する変更の流れ

READMEの例ではselect * from dolt.statusで未ステージの新規テーブルを確認し、select dolt_add('teams', 'employees', 'employees_teams')でステージします。その後dolt_commitをメッセージ付きで呼び出し、dolt.logで新しいコミットと初期化コミットを読みます。PostgreSQLのトランザクションとは別に、Doltの履歴操作を明示する流れです。

この差は運用設計に直結します。通常のSQL変更を誰がいつDoltコミットにまとめるか、ブランチをどの単位で作るか、カスタムリモートへどう送るかを決める必要があります。DoltgresではDoltHubやDoltLabへ直接プッシュできず、ファイルシステムやS3などのカスタムリモートが前提です。

互換性の空白を先に洗う

READMEはGit形式のバージョン管理CLIを提供しないことを明記しています。GSSAPIと拡張機能のサポートもなく、PostgreSQLの構文、型、関数、機能には未実装部分があります。バックアップとレプリケーションは進行中です。既存システムを移す場合、接続成功を互換性の証拠にしてはいけません。

pg_dumpで抽出したスキーマと代表データを隔離環境へ入れ、アプリケーションのマイグレーション、主要クエリ、接続プール、バックアップ復元を順に実行します。失敗したSQLは機能名と再現条件をissueに記録できます。READMEが示すサポート方針は、欠落機能があればリポジトリで報告するというものです。

ベンチマーク数値の読み方

READMEにはDoltgres 0.50.0とPostgreSQLをSysbenchで比較した結果があります。読み取り、書き込み、総合の倍率が掲載され、別にsqllogictestの結果も示されています。ただし、これらはREADMEが提示したテスト条件の値であり、利用するスキーマ、クエリ、ストレージ、同時実行数を変えた環境へ自動的に移せる性能保証ではありません。

評価では自分の代表クエリを固定し、PostgreSQL側とDoltgres側で同じデータ量、インデックス、接続数を用意します。レイテンシだけでなく履歴操作と復元時間も測るべきです。ライセンスはApache-2.0ですが、データベースのベータ表記と未実装機能はライセンスとは別の採用リスクとして扱います。

導入時の比較表には、PostgreSQLで利用している拡張、型、関数、認証方式、レプリケーション方式を行単位で並べます。Doltgres側では各項目を実行結果、未実装、代替手順に分け、単に接続できたかではなく移行後に失われる運用機能を見えるようにします。ブランチを作った後のマージ競合も、同じ行を別々に変更したケースとスキーマを変更したケースで試します。履歴を残せることがアプリケーションの整合性を自動で守るわけではないため、コミット前のレビューと復元テストを既存のデータベース変更管理へ組み込みます。

Doltgres固有の確認として、dolt.statusのstaged列、dolt.logのコミットメッセージ、ブランチ切り替え後の表内容を順に取得します。PostgreSQLの通常バックアップとDoltの履歴が別物であることを担当者が理解できるよう、復元先を分けて手順化します。

実データを扱う前に、employeesとteamsの例を使って追加、変更、削除、ブランチ、マージを実行します。dolt.logの履歴とpsqlから見える現在値を両方保存すれば、操作の意味を説明できます。

DoltgresはPostgreSQLの表を履歴付きで扱うベータデータベースを受け入れる前に、README記載の入力、実行、出力を一つの記録へまとめます。成功した操作だけでなく、失敗した操作、未確認の機能、利用した版、設定値、保存したログの場所も残します。担当者が同じ環境を作り直し、同じ確認結果を再現できることを条件にします。性能や互換性について数値を扱う場合は、データ量、実行時間、エラー数、資源使用量を測定条件とともに記録します。READMEにない保証は採用理由へ加えず、未確認事項として次の検証に回します。

編集部の結論

既存のPostgreSQL運用に履歴、差分、分岐を持ち込みたい開発チーム向けです。一般的な拡張機能、GSSAPI、DoltHub連携、完成したバックアップやレプリケーションが必要な環境にはそのまま向きません。導入前にpg_dumpとpsqlで実データを移し、使う型、関数、拡張機能を照合し、dolt.statusとdolt.logを含む復旧手順を試してください。

公式情報源

1. Official README
2. Project repository
3. Release notes