Databricks Lakebase：Unity Catalog 経由の分析はどこで動くか、Free Edition で確かめてみた

Posted at 2026-07-04

1. はじめに

本記事は 2026-07-04 時点・Databricks Free Edition での実測です。LTAP は 2026-06-16 発表でロールアウトの途中のため、提供状況や挙動は今後変わってくると想定されます

2026 年 6 月の Data + AI Summit で、Databricks が LTAP（Lake Transactional/Analytical Processing） を発表しました¹²。ひとことで言うと、「トランザクション（OLTP）と分析（OLAP）を、別々のエンジンではなくストレージ層で分ける」という考え方です。

HTAP（Hybrid Transactional/Analytical Processing）は本来、同じデータベースの中に行形式と列形式の両方を持ち、トランザクションと分析を 1 つのシステムで捌く、という考え方です。AlloyDB の列指向エンジン、TiDB の TiFlash、Oracle Database In-Memory などがこの形を実装しています。LTAP は、この列形式をデータベースの内部でなく、コンピュートから切り離したオブジェクトストレージ（Delta / Iceberg = Parquet）に 1 コピーだけ置き、それを OLTP と分析の両方が読む、という形を取ります。ETL や CDC でデータを別基盤へコピーして同期するのではなく、同じ 1 コピーを共有して読み手のコンピュートだけ分ける発想で、ストレージを共有する Aurora のリードレプリカに近いイメージです。公式ブログの表現を借りると、分析クエリは「Postgres 側の読み取りトラフィックにまったく影響しない（Postgres itself serves none of the analytical read traffic）」とされています¹。

OLTP と分析を別々のシステムに分け、CDC（変更データキャプチャ）でつなぐ構成（取り込み負荷をかけて挙動を見る検証）を何度か触ってきた延長で、「その分離をストレージ層に移して、パイプラインごと不要にする」というこの考え方を自分の手で確かめたくなりました。ちょうど Lakebase（Databricks のマネージド Postgres）は無料の Free Edition でも使えるので、ここに OLTP の書き込み負荷をかけながら、分析クエリを別々の経路で実行して、OLTP のレイテンシに影響が出るのか出ないのかを測ってみます。

なお本記事は、Lakebase / LTAP がどういう考え方で作られているかを手元で確かめてみるのが目的で、他製品と優劣を比べるものではありません。

1.1. 確かめたいこと

Databricks が掲げる考え方を、確認できる形に 2 つに分解しました。

#	確かめること	確認できれば OK の状態
1	分析クエリは OLTP を邪魔しないか	書き込み負荷中に分析クエリを同時実行して、OLTP のサーバ側レイテンシが悪化するかどうかを、経路ごとに示せる
2	Unity Catalog 経由は「Postgres を経由しない分析」になっているか	その経路が Postgres を叩くか（フェデレーションか、列指向の直読みか）を実測で確定できる

1.2. 結論（先出し）

Unity Catalog に登録した Lakebase を SQL Warehouse から集計するという自然な経路（③）は、OLTP 書き込みレイテンシのばらつき（標準偏差）を基準の約 1.9 倍にした。Postgres に直接ぶつけた場合（②・約 2.3 倍）とほぼ同じで、③ も Postgres を叩いている（5.1 章）
その正体は JDBC フェデレーションだった。UC 登録の経路は集計を Postgres にプッシュダウンする（5.2 章）。つまり LTAP が主張する「Postgres を経由しない分析」には、まだこのワークスペースでは到達していない（2026-07-04・Free Edition）。LTAP は 2026-06-16 発表で、先行ロールアウト中である²
Free Edition のサーバレスは書き込みレイテンシの絶対値がウォームアップで大きく動くため、絶対値でなくばらつきで評価した。この変動自体が、同じ検証を再現するときの注意点である
現時点で OLTP を分析から守るには、分析を Postgres の外のコピーへ移すしかない。だがそのコピーを最新に保つには CDC（Reverse ETL）というパイプラインが要る。LTAP が狙う「分離・最新・単一コピー・パイプラインなし」の同時達成は、まだ来ていない

2. 検証環境

項目	内容
データベース	Databricks Lakebase（Autoscaling プロジェクト）
Postgres バージョン	PostgreSQL 17.10
コンピュート	8〜16 CU オートスケール（計測中は 8 CU に固定）。1 CU ≈ RAM 2 GB
エディション	Databricks Free Edition
リージョン	AWS us-west-2
分析エンジン	Databricks SQL Warehouse（Serverless Starter / Small）
クライアント	Windows 11 + WSL2 Ubuntu の pgbench 16.14 / psql / Databricks CLI v1.6.0
データ	pgbench SF100（`pgbench_accounts` 1,000 万行・約 1.5 GB）

Lakebase の CU（Compute Unit）は 1 CU あたり RAM 約 2 GB です³。今回の 8 CU は RAM 約 16 GB 相当で、データ（1.5 GB）は十分メモリに載ります。ディスク I/O を追い込む検証ではなく、分析と OLTP が同じ計算資源を奪い合うかを見るのが狙いなので、この構成で問題ありません。

Lakebase の実体は Databricks が買収した Neon の技術です。実際、pg_stat_activity を見ると neon_autoscaling_sql_exporter や vm-monitor（SET neon.file_cache_size_limit = '12201MB'）といった内部プロセスが確認でき、コンピュートとストレージを分離した Neon 由来の構成であることが確認できます。

3. LTAP の主張と、検証の組み立て

3.1. LTAP は何を分けているのか

LTAP のアーキテクチャは、ざっくり次の 3 つで構成されます¹。

SafeKeeper … WAL（書き込みログ）を Paxos ベースで複製し、Postgres の外に出す
PageServer … データを非同期に列指向（Parquet）としてオブジェクトストレージへ書き出す
ステートレスな Postgres … ストレージを持たず、トランザクションだけを捌く

分析側は、Postgres から現在のログ位置（LSN）を受け取り、オブジェクトストレージの列指向データを読み、まだ列指向化されていない直近の変更を PageServer からマージする。だから「分析の読み取りは Postgres を通らない」という主張になります。

3.2. 確かめ方：同じ書き込み負荷に、分析を 3 つの経路で実行する

考え方はシンプルです。OLTP の書き込み負荷（pgbench）は、ずっと同じ Lakebase Postgres にかけ続けます。その裏で、同じ pgbench_accounts のデータに対する分析クエリを、実行する経路だけ変えて同時に走らせ、Postgres 側の OLTP レイテンシがどう変わるかを見ます。分析の経路は次の 3 つを用意しました（以降は表の呼び名で書きます）。

呼び名	分析の当て先	Postgres を経由するか
① 分析なし	何も実行しない（基準）	—
② Postgres 直	psql で Postgres に集計 SQL を直接実行する	する
③ Unity Catalog 経由	Lakebase を UC に登録し、SQL Warehouse から集計	後述（実測で確定）

「分析なし」と「Postgres 直」は分かりやすい対照です。分析クエリを同じ Postgres で実行すれば当然競合するはず（Postgres 直）、何もしなければ基準（分析なし）。本命は「Unity Catalog 経由」で、これが LTAP の言う「Postgres を経由しない分析」に当たるのか（＝Postgres を叩かずに済むのか）を、②・① と比べて見極めます。

OLTP 負荷は pgbench の標準シナリオ（TPC-B 相当）、分析クエリは 1,000 万行の全件集計（GROUP BY で件数・平均・最大・最小）を使います。分析クエリ側は 8 CU を埋めるために複数本を並列で実行し続けます。

3.3. なぜ「サーバ側の実行時間」で測るのか

ここは計測設計の要点です。ローカル環境から us-west-2 までの往復遅延（RTT）は約 135 ms ありました。pgbench の 1 トランザクションはおよそ 7 往復するので、ネットワークだけで 1 件あたり約 1 秒かかり、クライアント側で見える TPS は 30 前後で頭打ちになります。この状態では、数ミリ秒単位のサーバ側の競合はクライアント側の数字に埋もれて見えません。

そこで、干渉の主計測には pg_stat_statements（Postgres が SQL 文ごとに記録するサーバ側の実行時間） を使いました。ネットワーク遅延を除いた、Postgres の中だけの時間を文単位で取れます。各計測の前に統計をリセットし、その計測の間に実行された文の平均・標準偏差・最大値を採ります。

ひとつ限界も書いておきます。RTT が大きいぶん pgbench のスループット自体も落ちており（クライアント側 30 前後の TPS）、Postgres にかかる OLTP の書き込みレートは、同一 VPC の近接クライアントより軽くなっています。つまり今回測っているのは「軽めの OLTP 負荷に分析を同居させたときの干渉」で、OLTP 負荷が重い状況ではより大きく出る可能性があります。ただし 3 経路すべて同じ条件（同じ RTT・同じ pgbench 設定）で Postgres 側の時間を比べているので、経路どうしの相対比較は成り立ちます。

この干渉は、計算資源の余裕しだいでもあります。今回は分析クエリを並列で回して 8 CU を埋め、競合が起きる状況をあえて作っています。CU に余裕があれば ②③ でも干渉は小さくなり、実際に並列 1 本では見えませんでした。ただし「③ が Postgres の計算資源を使う（フェデレーションである）」という構造自体は余裕の有無によらず変わらず、資源が逼迫したときに効いてきます。

もう一点、プローブに使う文を絞りました。pgbench の小さいテーブル（pgbench_branches は 100 行、pgbench_tellers は 1,000 行）は、32 クライアントで一斉に更新すると行ロック競合で最大 671 ms まで跳ね、分析干渉とは無関係のノイズになります。そこで干渉プローブは、行数の多い pgbench_accounts（1,000 万行）に対する 2 文だけに限定しました。

読み取り: SELECT abalance FROM pgbench_accounts WHERE aid = $1
書き込み: UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2

どちらも行ロックの競合が少なく、分析クエリが計算資源を使うと、その分だけ実行時間が伸びる文です。

② は Postgres へ直接、③ は SQL Warehouse 経由でフェデレーションされて Postgres へ届きます。① は分析なしの基準です。

4. 手順・実行

4.1. Lakebase の作成と接続

Lakebase の入口は、ワークスペース右上のアプリスイッチャー（ドット格子のアイコン）→ Lakebase → Autoscaling → New project にあります。プロジェクトを作ると production ブランチと databricks_postgres データベースが自動でできます。

接続とその後の操作は、ほぼすべて Databricks CLI で回せました。認証は OAuth です（このプロジェクトはネイティブの Postgres パスワードログインが無効で、enable_pg_native_login: false になっていました）。

# WSL 内。OAuth ログイン（一度だけブラウザが開く）
databricks auth login --host https://dbc-xxxxxxxx-xxxx.cloud.databricks.com --profile free-edition

# psql ラッパー（資格情報の発行まで CLI が自動で処理する）
databricks psql --project lakebase-ltap-test -- -c "SELECT version();"
# => PostgreSQL 17.10 ...

pgbench には、CLI でトークンを発行して PGPASSWORD に渡します。トークンは平文で保存せず、実行のたびに発行します。

# 接続情報（PGHOST 等は各自の値に）。パスワードはトークンを都度発行
export PGHOST=ep-xxxxxxxx.database.us-west-2.cloud.databricks.com
export PGUSER='your-account@example.com'
export PGDATABASE=databricks_postgres
export PGSSLMODE=require
export PGPASSWORD=$(databricks postgres generate-database-credential \
  projects/lakebase-ltap-test/branches/production/endpoints/primary \
  -p free-edition -o json | jq -r .token)

4.2. データ投入と分析側の出口

OLTP 用のデータは pgbench の初期化で入れます。

pgbench -i -s 100          # 1,000 万行・約 1.5 GB

分析側の出口（Unity Catalog 経由）は、Lakebase を UC に登録して用意します。

databricks postgres create-catalog lakebase_ltap -p free-edition \
  --json '{"spec": {"branch": "projects/lakebase-ltap-test/branches/production", "postgres_database": "databricks_postgres"}}'

これで SQL Warehouse から lakebase_ltap.public.pgbench_accounts として読めるようになります。この UC 登録は Lakebase 専用のマネージドカタログ（MANAGED_ONLINE_CATALOG）で、Free Edition ではネットワーク設定やプレビュー有効化を追加せず、この 1 コマンドだけで開通しました。外部の PostgreSQL / MySQL 等を Lakehouse Federation でつなぐ経路とは別物なので、接続オブジェクトの作成なども不要です。

ここで大事なのは、登録してもデータはレイクハウスにコピーされず、Postgres への参照リンクができるだけという点です。だから SQL Warehouse からの集計は、実データのある Postgres にフェデレーションされます（これが後で見る ③ の挙動につながります）。

4.3. 計測の回し方

分析クエリはどの経路も同じ並列数（4 本）で当て、かける圧力をそろえました。同じ 120 秒でも経路ごとに実行できた回数は変わりますが（1 クエリあたりの重さが違うため）、ばらつきを決めるのは瞬間の競合＝並列数なので、そろえるべきはこちらです。

もう一つ、Free Edition のサーバレスにはウォームアップのドリフトがあり、これが計測結果を大きく左右しました。CU を固定した直後は書き込みレイテンシが高く、10 分ほどかけて下がっていきます。そのため経路を順番に測ると、ウォームアップが進んだぶん後に測った経路ほど速く出て、経路そのものの差とドリフトが混ざってしまいます（測る順番＝ウォームアップの度合いが結果を支配する）。

そこで ① → ② → ③ を 1 ラウンドとして 3 ラウンド繰り返すインターリーブ計測にしました。各経路をコールド・中間・ウォームの状態で 1 回ずつ測って平均するので、単調なドリフトは全経路に等しく分散され、経路そのものの差だけが残ります。各計測（120 秒）の前に pg_stat_statements をリセットし、pgbench（32 クライアント）と経路ごとの分析クエリを同時に走らせ、終わったらサーバ側時間を採取します。並列 1 本だと分析クエリが軽すぎて干渉が見えなかったため、並列数を上げて 8 CU を埋めています。

5. 計測結果

5.1. Postgres を経由する経路は OLTP のばらつきを増やす

まず断っておくと、書き込みレイテンシの絶対値（平均・最大）は、そのまま経路の比較には使えませんでした。4.3 章のウォームアップのドリフトで、同じ経路でもラウンドが進むほど値が下がります。各経路の書き込み平均をラウンド順に並べると、どれも単調に低下しているのが分かります。

経路	書き込み平均 r1	書き込み平均 r2	書き込み平均 r3
① 分析なし	1.35 ms	0.85 ms	0.64 ms
② Postgres 直	1.59 ms	1.06 ms	0.68 ms
③ Unity Catalog 経由	1.27 ms	0.82 ms	0.56 ms

そこで絶対値でなく、各計測の中でのばらつき（標準偏差） で評価します。これは絶対レベルでなく振れ幅を見る指標なので、ドリフトの影響を受けにくく、「たまに遅くなる」度合い＝テールもよく表します。pgbench_accounts への読み書き 2 文、3 ラウンド平均です。

経路	読み取り平均	読み取り標準偏差	書き込み平均	書き込み標準偏差
① 分析なし	0.044 ms	0.025 ms	0.95 ms	1.01 ms
② Postgres 直	0.027 ms	0.192 ms	1.11 ms	2.30 ms
③ Unity Catalog 経由	0.021 ms	0.088 ms	0.88 ms	1.92 ms

読み取れることは 2 つあります。

Postgres 直（②） と Unity Catalog 経由（③） は、書き込み標準偏差が基準（① 1.01 ms）の 約 2.3 倍（2.30 ms） と 約 1.9 倍（1.92 ms） に増えた。読み取りのばらつきも同じ向きで大きい。分析クエリが Postgres の資源を一時的に奪う瞬間に、たまたま重なった OLTP の書き込みが待たされ、振れ幅として出る
要点は、③ が ② とほぼ同じ水準まで悪化していること。Unity Catalog 経由の分析も、Postgres 直と同じように Postgres を叩いている、という意味になる（その仕組みは 5.2 章）

絶対値がドリフトする中でも、② はどのラウンドでも書き込み平均が最も高く（上のラウンド別表）、ウォームアップの下降トレンドを一貫して上回っていました。Postgres 直の分析クエリの影響が、ドリフトに埋もれずに現れていると考えられます。

5.2. 「Unity Catalog 経由」は Postgres に集計をプッシュダウンしていた

Unity Catalog 経由が OLTP を悪化させた理由は、集計が Postgres 上で実行されていたからです。SQL Warehouse で集計している最中に pg_stat_activity を見ると、Postgres 側にこの文が現れました。

-- Postgres 側（pg_stat_activity）で観測された、プッシュダウンされた集計クエリ
SELECT "bid",COUNT(*),AVG("abalance"),MAX("abalance"),MIN("abalance")
FROM "public"."pgbench_accounts" GROUP BY "bid"

集計そのものが Postgres にプッシュダウンされ、Postgres の CPU で実行されています。実行計画でも Scan JDBC v1 Relation と External engine query が並び、この経路が JDBC フェデレーション（外部エンジンへの委譲）であることが確認できました。つまり Unity Catalog に登録しただけの現時点の経路は、分析を Postgres の外に出していません。

5.3. 読み取りの平均も「Postgres を叩いたか」を裏づける

副産物として、読み取り平均にも差が出ました。Postgres を叩く ②③ は読み取り平均が 0.021〜0.027 ms と、基準（① 0.044 ms）より速くなっています。

分析クエリの全件スキャンが Postgres を通ると、pgbench_accounts のページが Postgres のキャッシュに載り、OLTP の 1 行アクセス（主キー指定）がキャッシュヒットしやすくなって平均が下がるためです。分析なしの ① にはこの効果がなく、基準のまま。つまり ②③ が Postgres をスキャンした傍証になっています。絶対値がドリフトする書き込みと違い、これは同じ計測窓の中での相対差なので、そのまま読めます。

6. 考察

6.1. なぜ平均でなくばらつきで見るのか

理由は 2 つあります。1 つは 4.3 章で触れたウォームアップのドリフトで、書き込みレイテンシの絶対値（平均・最大）が計測窓しだいで動くため、経路の差を絶対値では語れないこと。もう 1 つは、今回のデータ量（1.5 GB）が 8 CU の RAM に収まり、OLTP の 1 行アクセスはほぼキャッシュヒットするので、平均そのものが分析クエリの有無で大きく動かないことです。分析クエリの全件スキャンが CPU やメモリ帯域を一時的に奪う瞬間に、たまたま重なった OLTP の書き込みが待たされ、それが ばらつき（標準偏差） として表面化するためだと考えられます。SLA を引く立場でも、平均より「たまに遅くなる」度合いのほうが問題になるので、ばらつきで評価するのが妥当です。

6.2. 現時点の Unity Catalog 経由は LTAP ではなくフェデレーション

5.2 章で見たとおり、現時点では Unity Catalog に登録しただけの経路は集計を Postgres にプッシュダウンします。公式の位置づけを確認しておきます。

LTAP は 2026-06-16 発表で、「既存 Lakebase 顧客へのアップグレードとしてロールアウト中、広い提供は今後」とされる²。ブログも将来形で「今後数か月でロールアウトし、Lakebase のテーブルがそのまま Lakehouse 並みの性能で分析可能になる」と書いている¹
Free Edition の制限ドキュメントに Lakebase として明記されているのは「1 アカウントにつき 1 プロジェクト・scale-to-zero」だけで、LTAP の可否には触れていない⁴
Unity Catalog 登録の読み取り経路について、公式ドキュメントは「読み取り専用のクロスソースクエリ」とだけ述べ、フェデレーションか列指向直読みかを明言していない⁵

「本記事の時点（2026-07-04）の Free Edition では、単一コピーの LTAP はまだ実装されておらず、Unity Catalog 経由は JDBC フェデレーションである」と言えます。フェデレーションであること自体は実測（プッシュダウンされる実クエリ）で確認できましたが、これが公式に「フェデレーション」と説明されているわけではないので、将来挙動が変わりうる可能性はあると考えています。

6.3. 現時点で OLTP を分析から守るには、まだパイプラインが要る

現時点の Free Edition で「分析が OLTP を邪魔しない」を実現するには、分析を Postgres の外へ出すしかありません。UC 登録の経路（③）はフェデレーションで Postgres を読む形になります。Postgres の外にデータのコピーを持てば OLTP は守れますが、そのコピーを最新に保つには Reverse ETL（本記事時点では Public Preview）などのようなCDC経路が必要です⁶。つまり現時点は「最新だが Postgres を叩く（フェデレーション）」か「Postgres を叩かないがパイプラインが要る（コピー＋CDC）」のどちらかです。

公式ブログによれば、LTAP はこの 2 つを単一コピーで（パイプラインなしに、最新のまま、Postgres を経由せず）両立させることを目指しています¹。その統合が、本記事の時点の Free Edition にはまだ来ていない、というのが今回の結論です。

7. まとめ

確かめたかった 2 点の結果です。

#	確かめること	結果
1	分析クエリは OLTP を邪魔しないか	経路しだい。Postgres を経由する経路（Postgres 直・Unity Catalog 経由）は OLTP 書き込みのばらつきを約 2 倍にした
2	Unity Catalog 経由は「Postgres を経由しない分析」か	いいえ。JDBC フェデレーションで Postgres にプッシュダウンされる。単一コピーの LTAP は 2026-07-04 時点の Free Edition には未提供で、先行ロールアウト中

LTAP が目指すのは「分析を OLTP から切り離しつつ、単一コピーで最新のまま読む」ことです。今回測った限りでは、自然に使う Unity Catalog 経由の分析は JDBC フェデレーションで Postgres を叩き、OLTP のばらつきを増やしました。Postgres を経由しない列指向の直読み（LTAP がうたう姿）は、少なくとも現時点の Free Edition にはまだ提供されていません。新機能の説明は、手元の環境で経路まで確かめて初めて、どこまで来ているかが分かる、というのが今回の収穫でした。ロールアウトが進んだら、Unity Catalog 経由が列指向直読みに変わるかを同じ手順で測り直したいと思います。

8. 参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up