本記事は PostgreSQL Advent Calendar 2025 12月4日の記事です。
これまでの OrioleDB に関する記事は OrioleDBタグで検索してください。そもそも OrioleDB とは何ぞや、と言う方は、OrioleDB を触ってみるやこちらのスライド資料を参照ください。
これまでも OrioleDB に関する記事をいくつか書いてきました。これまでは、OrioleDB はどんなものであるか、触ってみよう、調べてみよう、仕組みはどうか？ 性能はどうか？ といった切り口でした。2025年12月時点でも beta (2025年10月末リリース beta13) ではあるものの、そろそろ「実際に使うため」の課題をテーマにしていこうかと思います。
OrioleDB のデプロイメント手段
これまではソースビルドして導入する手順を示してきました。コードを調べたりバグ報告をするには良いですが、本番運用では、通常はより手間のかからないデプロイメント手段を使うものでしょう。
ソースビルドすることなしにOrioleDBを使う方法には次のものがあります。
クラウドサービス
Supabase の DBaaS ではデータベースエンジンに PostgreSQL に加えて OrioleDB も選択できます。Supabase は BaaS（Backend as a Service）プラットフォームとして知られていて、2024年4月からは OrioleDB 開発を主導している会社でもあります。
ただし、今も「Public Alpha」扱いであって「is not production ready」と表示されます。また、OrioleDB を選ぶ動機は OLTPワークロードでの性能スケールアップがメインであろうかと思います。クラウドサービスの場合、そのメリットを享受するには主としてサービス提供側であり、利用者は性能とコストの見合いで選択するだけ、ということも言えます。
Supabase のサービスを使うことは、PostgreSQL で動作させてきたアプリケーションとの互換性を検証する目的であれば、一番手軽ですので良いと思います。
Docker image
Docker Hub に OrioleDB がすぐに使えるイメージが以下の 2系統から公開されています。
このうち、orioledb/orioledb の方には PostgreSQL 16、17 系に対する最新beta版が用意されています。supabase/postgres の方は PostgreSQL 17系むけのみ最新beta版が用意されており、x86_64 のみならず arm64アーキテクチャのものもあります。
さて、コンテナイメージも立派なデプロイメント手段ですが、公式配布されているイメージが運用むけになっているかという点が課題となります。配布イメージは真っ新な OrioleDB インストレーションですが、実運用むけには起動したらすぐにサービス利用可能な状態にしたいわけで、イメージの調整が必要となります。
なお、[Dockerイメージの構築手順]についても OrioleDB のドキュメントに記載があります。
パッケージ
結局、パッケージがあれば良い、というところに落ち着きそうです。
OrioleDB は PostgreSQL の拡張ですが、残念ながら、様々な拡張のパッケージを収納している [PGDG yumリポジトリ]には含まれていません。
しかしながら、[Pigsty] の配布物には OrioleDB の rpmパッケージが 含まれていました。Pigsty は PostgreSQL とその拡張のパッケージ管理ツールであり、また、配布元です。pig コマンドを使ってインストールを行います。
pig コマンドを使って以下のように導入できます。この手順はおおむね Pigstyの[ドキュメント記載] に沿っています。
# curl -fsSL https://repo.pigsty.io/pig | bash
# pig repo add pigsty pgdg -u
# pig repo set
# pig ext install orioledb -v 17
インストール先は /usr/oriole-17/ 以下ディレクトリになります。
Pigsty で2025年12月時点で在るパッケージは PostgreSQL 17系の OrioleDB beta12 (2025年 7月リリースされたもの）のみでした。OrioleDB 開発グループが直接関与している、supabase DBaaS や Dockerイメージと比べると、最新版より少し遅れるようです。一方、対応プラットフォームは豊富で RHEL系の el8、el9、e10、アーキテクチャとしては x86_64 と aarch64 についてパッケージが用意されていました。さらに、rpmパッケージだけでなく、ubuntuむけのdebパッケージもあります。
あとは、postgresユーザで以下のような環境変数を設定して、
ORIOLEHOME=/usr/oriole-17
export PATH=$ORIOLEHOME/bin:$PATH
export LD_LIBRARY_PATH=$ORIOLEHOME/lib:
export PGDATA=/var/lib/pgsql/17/odata
以下のようにセットアップできます。今回はテンプレートデータベースにorioledb拡張を含める方法にしました。
$ initdb --no-locale -E UTF8
《出力省略》
$ vi $PGDATA/postgresql.conf
shared_preload_libraries = 'orioledb'
logging_collector = on
$ pg_ctl start
waiting for server to start....2025-12-02 17:04:11.928 JST [1802] LOG: registered custom resource manager "OrioleDB resource manager" with ID 129
2025-12-02 17:04:11.957 JST [1802] LOG: redirecting log output to logging collector process
2025-12-02 17:04:11.957 JST [1802] HINT: Future log output will appear in directory "log".
done
server started
$ psql -d template1 -c 'CREATE EXTENSION orioledb'
CREATE EXTENSION
$ createdb odb1
$ psql -d odb1 -c 'ALTER DATABASE odb1 SET default_table_access_method TO orioledb;'
ALTER DATABASE
アプリケーションへの透過的な適用
OrioleDB をデプロイメントしたとして、次に必要なことは、PostgreSQL むけのアプリケーションを「透過的に」OrioleDB に載せることです。アプリケーションの中身に関知しないまま、データベースを OrioleDB にするにはどうしたらよいでしょうか。
方針その１: インストーラに OrioleDB を PostgreSQLとして見せる
スーパーユーザ権限のユーザと、ホスト、ポートを指定したら、そこに接続して、CREATE DATABASE して、自分が使うデータベース定義と初期データを投入する、というタイプのインストーラであれば、構築済みの OrioleDB を接続先として指定すれば良いことになります。このとき、そのスーパーユーザについて、あらかじめ以下を行っておきます。
$ psql -d template1 -c 'ALTER ROLE my_superuser SET default_table_access_method TO orioledb;'
ALTER ROLE
あるいは、postgresql.conf で以下を設定しておきます。
default_table_access_method = orioledb # デフォルトの heap をコメントアウト
インストーラがデータベース定義のときに、明示的にテーブルアクセスメソッドが heap であると指定する SET文や CREATE TABLE文を実行しないのであれば、これでうまくいきます。ただし、pg_dump で取得したダンプを投入する、という作りですと、ダンプ出力内には明示的な default_table_access_method の指定が入ってきますので、うまくいきません。
方針その２: インストール後にデータベースをダンプしてリストア
方針その１でうまくいかない場合、インストール後のデータベースをダンプして、書き換えて、リストアすることで、OrioleDB化します。
$ pg_dump --clean --create -U postgres -d appdb -f appdb.sql
$ grep default_table_access_method appdb.sql
SET default_table_access_method = heap;
$ cat appdb.sql \
| sed -E 's/SET default_table_access_method = heap/SET default_table_access_method = orioledb/' \
> appdb_orioledb.sql
$ psql -U postgres -f appdb_orioledb.sql
既存データベース削除（--clean）と作成（--create）のオプションを付けてダンプを取得します。ダンプの中には「SET default_table_access_method = heap;」といった指定が含まれているはずですので、その中の heap を orioledb に書き換えます。最後にそれをリストアすれば、OrioleDB化されたデータベースが得られます。
今回はアプリケーション導入直後というストーリーでした。既に PostgreSQL上で運用を行っていて巨大なデータを持っている場合には、定義とデータを分離してダンプを取得して、sedで書き換えを行うのは定義のダンプファイルだけ、とすればよいでしょう。その場合でも、データの再投入は避けられません。そうでないとテーブルアクセスメソッドを変えることはできません。
なお、OrioleDB にはいくつか[制限事項]がありますので、アプリケーションが発行している SQL によっては、機能しない、ということはあります。それはそれで検証・調査が必要です。
次の話: PITR バックアップ／リストア
OrioleDB のデプロイ方法とアプリ適用について述べました。
引続き、実運用で使いそうな機能なのに OrioleDB のドキュメントには書いていない事柄を順次取り上げていきます。
次は PITR (Point in Time Revcovery) が可能なバックアップ・リストアについて書きます。これは 12月 8日公開の SRA Advent Calendar 2025 12月 8日の記事として記載します。