Supabaseは2026年10月27日(現地時間)、Postgres向けのオープンソースストレージエンジン「OrioleDB」のパブリックベータ提供開始を発表した。これは、同社の全プランで利用可能となる。発表は「Supabase Select」イベントで行われ、更新頻度の高いテーブルでの性能向上を目指す。
Postgresのデフォルトストレージエンジンであるヒープは、行の更新時に古いバージョンをデッドタプルとして残す。これによりテーブルやインデックスが肥大化する「ブロート」が発生し、クエリの遅延やVACUUM処理の負担増につながっていた。高並行性環境や書き込み負荷の高いワークロードでも限界があった。
OrioleDBは、PostgresのTable Access Methodを通じてヒープを置き換える。行の更新や削除時に以前のバージョンをundoログに記録し、自動的に回収するため、デッドタプルの蓄積を回避する。64ビットのトランザクションIDを採用し、IDのラップアラウンド問題を解消した。行をプライマリキーインデックス内に格納するインデックス構成テーブルであり、プライマリキー検索時の読み取り構造を一つに統合する。さらに、インメモリページがストレージページに直接リンクするため、バッファマッピングでの競合を避ける。チェックポイントは変更されたデータのみを書き込むコピーオンライト方式を採用し、書き込み負荷の高いワークロードでのディスクI/Oを削減する。OrioleDBは2021年から開発が進められてきた。
Supabaseがホスト型Postgresのベンチマークサイト「DBArena」で実施したベンチマークによると、データがメモリに収まらないシナリオにおいて、OrioleDBはテスト対象の全コンピューティングサイズで、価格あたりのスループットが最も高かった。8XLインスタンス（32vCPU、128GiB RAM）では、ヒープストレージ上のSupabase Postgresと比較して、1分あたりのトランザクション数が約1.8倍に増加し、113,850トランザクション/分を達成した。スモールサイズでは、ヒープより約46%高い価格あたりのスループットを示した。
データがメモリに収まるシナリオでは性能差は縮小する。ラージサイズでヒープより約13%優位、8XLで約29%優位だった。スモールサイズではヒープが上回る結果となった。OrioleDBは、注文状況、在庫数、ジョブキュー、セッションデータなど、更新または削除が頻繁に行われるテーブルや、データセットがメモリよりも大きい場合、多数の接続が同時に読み書きを行う大規模インスタンス、およびプライマリキーによる行検索が多いワークロードで特に効果を発揮する。
今回のパブリックベータはテスト用途であり、SLA（サービス品質保証）は提供されない。OrioleDBはプロジェクト作成時に選択する必要があり、既存のプロジェクトに追加したり後から削除したりすることはできない。また、Point-in-Time Recovery（指定時点復旧）機能は利用不可であり、バックアップを新しいプロジェクトに復元することもできない。ネイティブのB-treeインデックスが最高のパフォーマンスを発揮し、pgvector HNSWを含む他のインデックスタイプは実験的なブリッジを介して動作する。CLUSTERやVACUUM FULLなど、一部のコマンドはOrioleDBテーブルでは機能しない。さらに、OrioleDBイメージにはplv8、plls、plcoffee、timescaledb-apacheなどのエクステンションは含まれない。OrioleDBプロジェクトではMultigresとの併用は不可能であり、自己ホスト型Supabaseスタックの一部としては未対応である。
参考: Supabase Blog (アーカイブ) — 2026年10月28日 09:00 (JST)
原文ハイライト"OrioleDB, an open-source storage engine for Postgres, is now in public beta"