Cloudflare Basin is GA: connecting Pipelines, Catalog, and SQL and understanding costs

Map the rename, GA, and three components first

The October 1 GA announcement and product overview confirm that Cloudflare Data Platform is now Basin. Cloudflare Pipelines becomes Basin Pipelines, R2 Data Catalog becomes Basin Catalog, and R2 SQL becomes Basin SQL. Existing resources and configuration explicitly continue working. There is no evidence that the rename requires deleting old resources, rebuilding tables, or immediately rewriting every query.

The components serve different stages. Pipelines ingests events and can transform them with SQL before writing to R2. Catalog manages Apache Iceberg table metadata and maintenance. SQL queries data on R2. Supported sinks include JSON, Parquet, and Iceberg. Open formats provide a path for other compatible engines, but do not automatically make every external tool, table version, and SQL dialect compatible.

Scenarios worth trying and capabilities still to come

A concrete starting point is request analytics: a Worker records path for each request, Pipelines sends events into an Iceberg table on R2, and SQL counts them by path. Product telemetry or agent-activity data are other candidates. Verify schema, write latency, query results, and costs on isolated samples before deciding whether to replace an existing analytics chain. GA does not validate your workload.

The announcement places custom partitioning, schema migration, more updatable pipeline configuration, Iceberg V3 with Variant, and stateful streaming aggregation/joins on the future roadmap. Finer-grained Catalog authorization and jurisdiction, and direct SQL DDL and geospatial features, are also planned. Do not describe these future items as currently available just because the platform is GA. This article has not verified production performance, account activation, or delivery dates for these plans.

Keep the throughput conflict in capacity planning

As of verification, the Pipelines limits page and October 1 stream-ingestion limit update state 1 GB/s per stream, while the GA blog says 3 GB/s. Official materials conflict. This article does not decide which number has taken effect for all accounts or treat 3 GB/s as an SLA. Plan capacity using the current limits documentation's 1 GB/s, and verify actual account allowances with Cloudflare for higher requirements.

The current limits page also lists up to 20 streams, 20 sinks, and 20 pipelines per account, with 5 MB per request. A stream is an ingestion endpoint, a sink is a destination, and a pipeline is connection and transformation configuration; their IDs are not interchangeable. Consider event size, transformed output volume, writes to multiple destinations, and consumption latency. Free ingress does not bypass technical limits.

Estimate costs by dimension, with R2 separate

The current consolidated pricing page lists monthly included usage separately. Stream ingress is free with no usage-billing cap. SQL transforms include 50 GB per month, then cost $0.04/GB. Sink delivery shares a monthly 50 GB allowance; JSON overage is $0.03/GB, while Parquet or Iceberg is $0.06/GB. Sinks meter uncompressed data delivered to each destination, not compressed object size.

Catalog charges for operations and optional compaction, with both compaction dimensions applying only when enabled. Basin SQL meters compressed data scanned from R2, including 10 GB per month and then charging $0.0025/GB. Each query has a minimum billed scan of 10 MB. Queries that fail before or during execution incur no SQL scan fee. Metadata-only operations such as EXPLAIN, SHOW, and DESCRIBE do not scan data, but related R2 or Catalog operations may still be charged.

These tables exclude R2 storage and read/write charges and do not waive Workers Paid fees. R2's lack of egress-bandwidth charges does not imply zero total cost. Budget input volume, transformation volume, uncompressed sink output, Catalog operations/compaction jobs, compressed SQL scans, and query counts separately, and check current R2 pricing. Multiple destinations and many small queries change the bill. This article has no actual account bill for verification.

Validate the smallest working chain with the official request-analytics example

The official Wrangler guide requires Workers Paid, enabled R2, and local Node.js/npm. Its query example also requires an R2 Account API token with Admin Read & Write permission. Grant and protect it according to actual need; do not put the token in a public repository, Worker, or wrangler configuration. The following explains documented steps. This article has not created a token, deployed a Worker, or written real data.

1. In an isolated project, run npx wrangler basin pipelines setup --name request_events. Follow the guide to disable the HTTP endpoint, define the required path string field, select a test R2 bucket, and use an Iceberg sink/Catalog. Do not connect production data and then experiment.
2. Run npx wrangler basin pipelines streams list to find the stream ID. In pipelines in the root wrangler configuration, set binding to EVENTS and stream to that ID. This needs a stream ID, not a pipeline ID.
3. In the Worker's request handler, use await env.EVENTS.send([{ path: new URL(request.url).pathname }]) to send events. Deploy the test Worker and request several paths according to the guide. The platform handles binding authentication; do not put the SQL query token in the Worker.
4. Use npx wrangler basin catalog get <YOUR_BUCKET> to find the warehouse name. Set WRANGLER_BASIN_SQL_AUTH_TOKEN in your local terminal, then run npx wrangler basin sql query "<WAREHOUSE_NAME>" "SELECT path, COUNT(*) AS requests FROM default.request_events GROUP BY path ORDER BY requests DESC".
5. Compare request paths and counts, which may include requests such as /favicon.ico. If the table is missing or temporarily has zero rows, the guide recommends waiting a few minutes for the first file to be written before querying again. Zero rows do not directly mean lost data. Also check stream ID, schema, sink status, bucket/Catalog, and query permissions.

Existing users should check configuration before expanding to business data

Existing Pipelines, R2 Data Catalog, or R2 SQL users should list current streams, sinks, tables, queries, and usage, and confirm that corresponding resources remain discoverable after the rename. Retain original schemas and query baselines and check writes and results with isolated samples. Do not duplicate production resources because of a rename or assume roadmap items already solve schema migration or permission requirements.

For new integrations, first establish an explainable path: which events were sent, when a file formed, which table was queried, and how usage is billed. Use the proxy connection troubleshooting checklist only with network evidence such as connection timeouts, TLS, or proxy authentication errors. Network tools cannot change Paid eligibility, service limits, or SQL semantics. Update this same assessment when new official materials clarify throughput, released features, or pricing, rather than treating unconfirmed items as launch promises.