Cloudflareが新データ基盤「Basin」を一般提供　Iceberg対応、R2のエグレス無料を活用

Cloudflareは2026年10月1日、データ分析基盤「Cloudflare Basin」の一般提供を開始した。従来のCloudflare Data Platformを改称したもので、イベントの取り込みから保存、SQLによる分析までを一連のサービスで扱える。ベータ開始時にはフィルター検索が中心だったSQL機能も拡張され、現在は複数のテーブルを結合した分析まで行えるようになった。

Basinの特徴は、データの保存先と分析に使うエンジンを分けて選べる点にある。Apache Icebergで管理するデータは外部の対応エンジンからも読み取ることができ、R2から外部へ転送する際のエグレス料金もかからない。

ただし、データの変換や書き出し、検索、テーブル管理にはそれぞれ料金や制限がある。どの処理をBasinに任せ、どこから外部の分析基盤を利用するかによって、運用の複雑さと実際の費用は変わる。

名称変更だけでなく、複数テーブルを扱える分析基盤へ

Basinは、役割の異なる3つのサービスで構成される。Basin PipelinesはHTTPやWorkersからイベントを受け取り、SQLで加工して保存する。Basin Catalogは、保存したファイルをテーブルとして扱うためのメタデータ管理と保守を担う。そしてBasin SQLが、Catalogで管理されたテーブルをSQLで検索・分析する。

旧名称はそれぞれCloudflare Pipelines、R2 Data Catalog、R2 SQLで、既存の設定は引き続き利用できる。

データの取り込み、保存、分析を組み合わせる構成や、外部の分析エンジンから同じデータへアクセスできる設計は、今回初めて登場したものではない。Cloudflareが2025年9月25日に発表したData Platformの段階で、すでにこの3層は用意されていた。

一方、当時のR2 SQLはフィルター検索を中心とする初期ベータ版で、複雑な集計などは今後の拡張項目とされていた。

現在のBasin SQLは、テーブル同士の結合や集計に加え、順位付けなどに使うウィンドウ関数にも対応する。例えば、利用イベントと契約情報を結び付け、料金プランごとに利用量の多い顧客を抽出するといった分析ができる。単独のログから条件に合う行を探すだけでなく、複数のデータを組み合わせて業務上の問いに答えられる段階へ機能が広がった。

GA時の変更履歴では、共通テーブル式（CTE）や実行計画の確認にも対応したと説明している。

Pipelines側も機能が拡張されている。Cloudflareのログを転送するLogpushと接続し、保存前にデータを絞り込んだり整形したりできるほか、イベントの項目や型を定義したスキーマからWorkers向けの型を生成し、項目不足や型の不一致を検出する仕組みも加わった。

保存前にデータの形式を揃えておけば、後の分析で扱うデータ量を減らし、データの不整合も抑えやすくなる。

ただし、保存済みのテーブルをBasin SQLで結合する処理と、流入し続けるイベントを継続的に結合・集計する処理は別である。後者には、過去のイベントや途中の計算結果を保持しながら処理する仕組みが必要になる。Cloudflareの発表では、Pipelinesでこうした処理を可能にする機能は今後の計画に含まれている。

Icebergでデータ形式を共有し、R2で外部利用時の転送料を抑える

Apache Icebergは、データ分析そのものを実行するエンジンではない。どのデータファイルがどのテーブルに属するのか、列の定義は何か、ある時点でどのファイルがテーブルを構成していたのか、といった情報を管理するための共通形式である。

実際の行データはParquetなどのファイルに保存される。Icebergの仕様では、データ本体と、それらをテーブルとして管理するためのメタデータを分けて扱う。

この共通形式を採用することで、保存したデータをBasin SQLだけで読む必要がなくなる。Cloudflareは、DuckDBやSpark、SnowflakeなどのIceberg対応エンジンから同じテーブルを利用できるとしている。

用途に応じて分析エンジンを選ぶ際、データを各製品専用の形式へ変換し直す手間を減らせる。ただし、Icebergで管理されているからといって、対応機能やSQLの書き方まで各エンジンで完全に共通になるわけではない。

ここにR2のエグレス料金無料という特徴が加わる。別のクラウドで分析エンジンを動かしていても、R2から外部へ転送したデータ量に応じた帯域料金はCloudflare側では発生しない。

共通形式でデータを保存できることと、そのデータを外部の分析基盤から利用する際の転送コストを抑えられることを組み合わせた設計といえる。ただし、外部エンジン側の計算料金や、接続先サービスの従量課金は別途発生する。

また、共通形式で保存すれば、それだけで大規模データを高速に検索できるわけではない。Cloudflareが公開したSQLエンジンの設計では、日付によるパーティションや列の最小値・最大値などを調べ、検索条件に合わないファイルを読み飛ばす。

さらにParquetファイル内部の行グループも絞り込み、必要な処理をWorkersへ分散する。すべてのデータを読み込む前に、検索対象そのものを減らす仕組みだ。

Pipelinesが高い頻度でファイルを書き出すと、新しいイベントをすばやく保存できる一方、小さなファイルが大量に作られる。ファイル数が増えれば、検索時に個々のファイルを開く処理が増え、ファイル一覧を管理するメタデータも大きくなる。

Catalogの自動保守機能は、こうした小さなファイルをまとめて大きなファイルへ再構成する。また、過去時点のテーブル状態を記録するスナップショットを、設定した保持条件に従って失効させ、参照されなくなったファイルを削除することもできる。

保守に関する文書が扱っているのは、データが継続的に増える環境で、検索性能と保存容量を維持するための処理である。

そのため、自動保守を有効にしても、過去の状態をどこまで保持するかは利用者が決める必要がある。保存容量を減らすために古いスナップショットを削除すれば、過去の特定時点までさかのぼって調査できる範囲も狭くなる。

エグレス無料でも、変換・書き出し・検索には料金がかかる

Basinでは、R2から外部へのエグレス料金が無料でも、データの変換、書き出し、検索などには別途料金が発生する。Pipelinesの書き出しは非圧縮時のデータ量、Basin SQLの検索は圧縮後の読み取り量を基準に課金される。

2026年10月5日時点のCloudflareの料金文書を、処理段階と計量基準ごとに整理すると次のようになる。PipelinesについてはWorkers Paid向けの月間無料枠、R2はStandardクラスの料金を示している。書き出しの無料枠は出力形式間で共有され、それぞれの行は異なる処理に対する料金を示す。

処理	月間無料枠	超過分の単価・計量基準
Pipelinesへのデータ取り込み	データ量による課金なし	無料。処理速度などの制限は別途存在
PipelinesのSQL変換	50GB	処理データ1GBにつき0.04ドル
Pipelinesの書き出し	50GB	非圧縮データ1GBにつきJSONは0.03ドル、Parquet／Icebergは0.06ドル
Catalogのメタデータ操作	100万操作	100万操作につき9ドル
Catalogの小ファイル結合	処理量10GB、100万ファイル	処理量1GBにつき0.005ドル＋100万ファイルにつき2ドル
Basin SQLの検索	読み取り量10GB	圧縮後の読み取り量1GBにつき0.0025ドル。1クエリにつき最低10MB
R2 Standardでの保存	10GB月	1GB月につき0.015ドル。読み書き操作の料金は別
R2から外部への直接転送	データ量による課金なし	無料。接続先サービスの料金は別

出典はCloudflareのPipelines料金、SQL料金、Catalog料金、R2料金である。

小ファイルの結合は、この機能を有効にした場合に課金される。表にはWorkers Paidの基本料金や、外部の分析エンジンにかかる計算料金は含めていない。

Pipelinesの公式例を見ると、課金される処理の違いが分かりやすい。月500GBのイベントをSQLで加工し、不要なデータを除いて300GBまで減らしたうえでIcebergテーブルへ書き出す場合、変換料金は「（500−50）×0.04」で18ドル、書き出し料金は「（300−50）×0.06」で15ドルとなる。Pipelines部分の合計は33ドルだ。

ただし、ここにはR2の保存料金やCatalogの料金は含まれていない。

保存前にデータを絞り込めば、書き出すデータ量や保存容量は減らせる。一方、その絞り込みを行うSQL変換自体にも料金がかかる。

また、Parquetを使って実際の保存容量を圧縮しても、Pipelinesの書き出し料金は非圧縮時のデータ量を基準に計算されるため、保存容量と同じ割合で書き出し料金が下がるわけではない。圧縮の効果が料金に直接反映されるのは、圧縮後のデータ量を基準とする保存やSQL検索の側だ。

検索時には、返された結果の大きさではなく、その結果を得るためにどれだけのデータを読み込んだかが重要になる。前述したファイルや行グループの読み飛ばしは、読み取り量を減らし、検索料金を抑えるうえでも効果がある。

ただし、検索に伴うR2の読み取り操作は別途計上され、少量の検索でも1クエリにつき最低10MBの読み取り量が適用される。

また、既存クラウドからR2へデータを移行する場合、移行元のクラウドで発生するエグレス料金までR2の「転送料ゼロ」で消えるわけではない。

採用判断では、SQLの制限とデータの配置を確認する

Basin SQLは現時点では読み取り専用で、検索対象となるデータファイルもParquetに限られる。SQLから行を追加、更新、削除する操作や、テーブルを作成・変更するDDLには対応していない。

Apache Icebergというテーブル形式そのものが備える機能と、Basin SQLから実際に利用できる機能は分けて考える必要がある。

制限に関する文書では、大規模な結合や集計がタイムアウトする場合があることも説明されている。

ウィンドウ関数など一部の処理では、実行前に必要なメモリ量を見積もり、対象データが多すぎる場合はクエリの実行自体を拒否する。既存の分析クエリを移行する場合は、SQL構文の互換性だけでなく、中間結果の大きさや、事前にどこまでデータを絞り込めるかも確認する必要がある。

サーバーを自分で用意する必要がないことと、あらゆるSQLをそのまま実行できることは別である。

データ取り込み速度については、Cloudflareの公開資料間で数字が一致していない。10月1日の発表ブログではストリーム当たり毎秒3GBと記載されている一方、制限表と同日の変更履歴では毎秒1GBとされており、従来の毎秒5MBから引き上げられたと説明している。

実装時には、公開されている制限表の毎秒1GBを基準とし、それ以上の処理能力が必要な場合はCloudflareへ確認するのが妥当だ。ブログに記載された3GB/秒を、すべての利用者に適用される上限と断定することはできない。

今後のロードマップにも、採用判断に関わる項目が残っている。Icebergの新しい仕様への対応に加え、Catalogではテーブル単位などの細かなアクセス制御や、データを保存する法域を指定する機能が予定されている。

データ所在地やアクセス制御が導入要件になる企業では、R2単体で利用できる機能からBasin全体の対応状況を推測せず、必要な機能がどこまで実装されているかを個別に確認する必要がある。

Basinの3つのサービスを、必ずすべて同時に採用する必要はない。既存の分析エンジンを残しながらCatalogだけを利用する構成も、Cloudflare上でデータの取り込みから保存、検索までをまとめる構成も選べる。

自社で使うクエリが現在の機能と制限の範囲に収まり、データ変換、保存、保守、検索まで含めた総コストを把握できれば、共通のIcebergテーブルを維持しながら、用途ごとに適した分析エンジンを選びやすくなる。