On October 1, 2026, Cloudflare announced the general availability of Cloudflare Basin, its data analytics platform. Basin is a rebrand of the earlier Cloudflare Data Platform, and it handles everything from event ingestion and storage to SQL analysis within a single set of services. The SQL capabilities have also expanded. During the beta they centered on filtered queries, but they now support analysis that joins multiple tables.
A defining feature of Basin is that you can choose the storage location and the analytics engine separately. Data managed with Apache Iceberg can be read by compatible external engines, and Cloudflare charges no egress fees when data is transferred out of R2.
That said, data transformation, writes, queries and table management each carry their own pricing or limits. Operational complexity and actual costs will depend on which workloads you leave to Basin and where you hand off to an external analytics platform.
More than a rename: an analytics platform that handles multiple tables
Basin consists of three services with distinct roles. Basin Pipelines receives events over HTTP or from Workers, processes them with SQL and stores them. Basin Catalog manages the metadata and maintenance needed to treat stored files as tables. Basin SQL then queries and analyzes the tables managed by Catalog.
The previous names were Cloudflare Pipelines, R2 Data Catalog and R2 SQL, respectively, and existing configurations continue to work.
Combining ingestion, storage and analysis, and allowing external analytics engines to access the same data, is not new with this release. The three layers were already in place when Cloudflare announced the Data Platform on September 25, 2025.
At that time, however, R2 SQL was an early beta centered on filtered queries, and complex aggregations were listed as future enhancements.
Basin SQL now supports joins and aggregations across tables, as well as window functions used for ranking and similar tasks. For example, you can link usage events with contract information and extract the highest-usage customers for each pricing plan. Its scope has grown from finding matching rows in a single log to answering business questions by combining multiple datasets.
The GA changelog also says Basin now supports common table expressions (CTEs) and inspection of query execution plans.
Pipelines has been extended as well. It connects to Logpush, which forwards Cloudflare logs, so data can be filtered and reshaped before it is stored. It can also generate types for Workers from a schema that defines event fields and types, and detect missing fields or type mismatches.
Standardizing data formats before storage can reduce the volume of data handled in later analysis and make inconsistencies easier to avoid.
However, joining stored tables with Basin SQL is different from continuously joining and aggregating a stream of incoming events. The latter requires a mechanism that retains past events and intermediate results while processing. According to Cloudflare's announcement, features enabling this kind of processing in Pipelines are part of its future plans.
Iceberg shares the data format, and R2 keeps external transfer costs down
Apache Iceberg is not an engine that runs analytics itself. It is a common format for managing information such as which data files belong to which table, how columns are defined, and which files made up a table at a given point in time.
The actual row data is stored in files such as Parquet. Under the Iceberg specification, the data itself is handled separately from the metadata used to manage it as tables.
Adopting this common format means stored data no longer has to be read only through Basin SQL. Cloudflare says the same tables can be used from Iceberg-compatible engines such as DuckDB, Spark and Snowflake.
When choosing an analytics engine for a given purpose, this reduces the effort of converting data into each product's proprietary format. Being managed by Iceberg does not, however, make supported features or SQL syntax completely uniform across engines.
R2's free egress adds to this. Even if you run an analytics engine on another cloud, Cloudflare does not charge bandwidth fees based on the amount of data transferred out of R2.
The design combines storing data in a shared format with keeping down the cost of transferring it to external analytics platforms. Compute charges on the external engine and usage-based fees for the connected service are separate.
Storing data in a shared format also does not, on its own, make queries over large datasets fast. In the SQL engine design published by Cloudflare, the engine examines date partitions and column minimum and maximum values, then skips files that do not match the query conditions.
It further narrows down row groups inside Parquet files and distributes the necessary processing across Workers. The mechanism reduces the search scope itself before reading all of the data.
When Pipelines writes files frequently, new events can be stored quickly, but a large number of small files are created. More files mean more work opening individual files during queries, and the metadata that tracks the file list also grows.
Catalog's automatic maintenance consolidates these small files into larger ones. It can also expire snapshots, which record past table states, according to configured retention conditions, and delete files that are no longer referenced.
The maintenance documentation covers processing meant to sustain query performance and storage capacity in environments where data keeps growing.
Even with automatic maintenance enabled, users must decide how much history to retain. Deleting old snapshots to save storage also narrows how far back you can investigate specific points in time.
Free egress, but transformation, writes and queries are billed
Even though egress from R2 is free, Basin separately charges for data transformation, writes, queries and more. Pipelines writes are billed on uncompressed data volume, while Basin SQL queries are billed on the compressed amount read.
The following summarizes Cloudflare's pricing documentation as of October 5, 2026, by processing stage and metering basis. For Pipelines it shows the monthly free allowance for Workers Paid, and for R2 it shows Standard class pricing. The write allowance is shared across output formats, and each row reflects pricing for a different operation.
| Operation | Monthly free allowance | Overage rate / metering basis |
|---|---|---|
| Ingesting data into Pipelines | No volume-based charge | Free. Separate limits such as throughput apply |
| Pipelines SQL transformation | 50GB | $0.04 per GB processed |
| Pipelines writes | 50GB | Per GB of uncompressed data: $0.03 for JSON, $0.06 for Parquet/Iceberg |
| Catalog metadata operations | 1 million operations | $9 per million operations |
| Catalog small-file compaction | 10GB processed, 1 million files | $0.005 per GB processed + $2 per million files |
| Basin SQL queries | 10GB read | $0.0025 per GB of compressed data read; 10MB minimum per query |
| Storage on R2 Standard | 10GB-month | $0.015 per GB-month; read/write operations billed separately |
| Direct transfer from R2 to external destinations | No volume-based charge | Free. Fees for the destination service are separate |
Sources are Cloudflare's Pipelines pricing, SQL pricing, Catalog pricing and R2 pricing.
Small-file compaction is billed when the feature is enabled. The table does not include the Workers Paid base fee or compute charges for external analytics engines.
The official Pipelines example shows clearly how the billed operations differ. Suppose 500GB of events per month are processed with SQL, unneeded data is removed to reduce the volume to 300GB, and the result is written to an Iceberg table. The transformation charge is (500−50)×0.04 = $18, and the write charge is (300−50)×0.06 = $15. The Pipelines portion totals $33.
This does not include R2 storage or Catalog charges.
Filtering data before storage reduces the volume written and the storage capacity needed. But the SQL transformation that does the filtering is itself billed.
Also, even if Parquet compresses the actual stored size, Pipelines write charges are calculated on uncompressed volume, so write costs do not fall in proportion to storage. The effect of compression shows up directly in storage and SQL queries, which are billed on compressed volume.
For queries, what matters is not the size of the returned result but how much data had to be read to produce it. The file and row-group skipping described earlier helps reduce the amount read and, with it, query charges.
R2 read operations incurred by a query are counted separately, and a 10MB-per-query minimum read volume applies even to small queries.
Moreover, when migrating data to R2 from an existing cloud, R2's zero transfer fees do not erase the egress charges incurred at the source cloud.
Before adopting, check SQL limits and data placement
Basin SQL is currently read-only, and the data files it can query are limited to Parquet. It does not support adding, updating or deleting rows via SQL, nor DDL for creating or altering tables.
Features of the Apache Iceberg table format itself should be considered separately from what is actually available through Basin SQL.
The limitations documentation also explains that large joins and aggregations may time out.
For some operations, such as window functions, the engine estimates the memory required before execution and refuses to run the query if there is too much data. When migrating existing analytical queries, you need to check not only SQL syntax compatibility but also the size of intermediate results and how far data can be narrowed in advance.
Not having to provision servers is different from being able to run any SQL as is.
On ingestion speed, Cloudflare's published materials do not agree. The October 1 announcement blog states 3GB per second per stream, while the limits table and the same-day changelog say 1GB per second, up from the previous 5MB per second.
For implementation, it is reasonable to plan around the 1GB per second in the published limits table and to check with Cloudflare if you need more capacity. The 3GB per second in the blog cannot be assumed to be an upper limit that applies to all users.
Some items relevant to adoption decisions also remain on the roadmap. In addition to support for newer Iceberg specifications, Catalog is slated to gain finer-grained access control, such as at the table level, and the ability to specify the jurisdiction where data is stored.
Companies for which data residency or access control is a requirement should check individually how far the needed features have been implemented, rather than inferring Basin's overall support from what R2 offers on its own.
You do not have to adopt all three Basin services together. You can use Catalog alone while keeping an existing analytics engine, or consolidate ingestion, storage and querying on Cloudflare.
If your queries fit within current capabilities and limits, and you can account for the total cost across transformation, storage, maintenance and querying, it becomes easier to keep a shared Iceberg table and choose the analytics engine that suits each use.