本文へ移動

AI Buildersのための最新のニュース、知見、事例を毎日お届け

運営会社
実行環境とインフラSupabase

Supabase、OrioleDBを全プランで公開ベータ 更新の多い表が膨らみにくい

米Supabaseは10月28日、Postgresの保存の仕組みを置き換える「OrioleDB」を全プランで公開ベータにした。更新や削除の多い表で古い行が溜まりにくく、料金は通常のPostgresと同じだが、本番向けではない。

記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談

毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

Supabase の OrioleDB の図。表の行の古い版が UNDO LOG に移る様子を示す
画像: Supabase

米Supabaseは10月28日、Postgresのデータの保存の仕組み(ストレージエンジン)を置き換えるオープンソースの「OrioleDB」を、全プランで公開ベータにした。新しいプロジェクトを作る時に選べ、料金は通常のPostgresと同じだ。更新や削除の多い表で古い行が溜まって表が膨らむ問題を、仕組みの側で減らす。ただし本番での利用はまだ想定しておらず、読者がアプリの裏側のデータベースとして試すなら、検証用のプロジェクトから始めることになる。

古い行が溜まる問題を減らす

Supabaseの公式ブログによると、Postgresの標準の保存形式「heap」は、行を更新しても書き換えず、新しい版を書いて古い版を「dead tuple」として残す。削除でも同じだ。古い版は「VACUUM」という処理が片付けるが、更新や削除の多い表では自動の処理が追いつかず、表とインデックスが中身より大きくなる。読むページが増えるので、問い合わせも遅くなる。

このため運用する側は、表ごとに自動VACUUMの設定を詰めたり、手でVACUUMを回したり、「pg_repack」で表を作り直したりしてきた。OrioleDBはこの手間を仕組みで減らす。更新や削除の前の版を「undo log」に書き、自動で回収するので、たいていの場合は表に古い行が溜まらない。

OrioleDBはPostgresの差し替え口「Table Access Method」を通じてheapを置き換える。接続文字列や認証、行単位のアクセス制御(RLS)、クライアントのライブラリは変わらない。

主キーで引く読み書きが速くなる

行は主キーのインデックスの中に収まり、主キーで引くと1つの構造だけを読めば済む。ほかのインデックスは主キーを指すので、更新では値が変わった列のインデックスだけを書き換える。heapでは、変えていない列のインデックスにも新しい項目が要ることが多かった。トランザクションのIDは64ビットになり、IDが一巡して書き込みが止まる心配もない。ただしシステムの表とheapの表は32ビットのままだ。

Supabaseは自社の比較サイト「DBArena」で、TPC-Cを元にした負荷を流して測った。データがメモリに収まらない条件では、32 vCPU・128 GiBの8XLで、heapの約1.8倍となる毎分11万3850件のトランザクションをこなした。一方、データがメモリに収まる条件では差は小さく、8XLで約29%、Largeで約13%の上回りにとどまる。最小のSmallではheapが勝った。Supabaseは、自分の負荷で測ってから判断するよう勧めている。

効くのは、注文の状態、在庫の数、ジョブのキュー、セッションのように、頻繁に更新・削除する表だという。pgvectorのHNSWなど、B-tree以外のインデックスは試験段階の仕組みを経由するので、まだ速くならない場合がある。

選べるのは作る時だけ

使い方は、ダッシュボードで新しいプロジェクトを作る時に「Advanced Configuration」を開き、「Postgres Type」で「Postgres with OrioleDB」を選ぶ。その後に作る表は、特別な書き方をしなくてもOrioleDBになる。手元で開発する時は、Supabase CLIの2.119.0以降で「supabase init --use-orioledb」を使う。今回の公開ベータは、OrioleDBのbeta19をPostgres 17.11の上で動かす。

制約も多い。保証(SLA)は無く、既存のプロジェクトに後から足すことも外すこともできない。時点を指定した復元(PITR)と、バックアップを新しいプロジェクトに戻す機能は使えない。「CLUSTER」や「VACUUM FULL」などのコマンドは動かず、「timescaledb-apache」などの拡張も入っていない。セルフホスト版のSupabaseにもまだ入っていない。細かな制約はOrioleDBの文書にまとまっている。OrioleDB本体はGitHubで公開されている。

Supabaseで動かすアプリの、更新の多い表が膨らむ問題に、追加の費用なしで別の選択肢ができた。ただし今は試す段階で、本番の表を移せる段階ではない。

編集部の見方

編集部は、今回の公開ベータを「本番の前に自分の負荷で測る機会」と見る。約1.8倍という数字は、データがメモリに収まらない8XLの条件の値で、小さな構成ではheapが勝った。数字の出どころは条件ごとに大きく変わる。エージェントでアプリを作る読者は、ジョブのキューやセッションの表のように更新の多い表を、検証用のプロジェクトに作って比べるとよい。後から切り替えられず、PITRも無いので、本番の表を載せる判断はまだ早い。正式版で制約がどこまで外れるかは、まだ分からない。

出典

に確認(日本時間)

  1. Supabaseの公式ブログ(supabase.com)
  2. OrioleDBの文書(supabase.com)
  3. GitHubで公開(github.com)

この記事をシェア

この記事は役に立ちましたか