CLOUDFLARE-HAMMER! R2 SQL schiebt JETZT echte JOINs in DEINEN Iceberg-Lake — Apache-Tabellen sprechen endlich miteinander

CLOUDFLARE-HAMMER! R2 SQL wächst zum richtigen Lakehouse

Cloudflare hat im Mai-Changelog still und leise ein Mega-Feature für sein R2-SQL-Produkt freigeschaltet: Multi-Table-JOINs auf Apache-Iceberg-Tabellen im R2 Data Catalog. Das klingt nach Daten-Geek-Talk, ist aber ein riesiger Sprung: R2 wird damit endgültig vom reinen Object-Storage zum echten Lakehouse.

SCHOCK: Welche JOINs jetzt gehen

Bisher konnte R2 SQL nur Single-Table-Abfragen — du musstest deine Iceberg-Tabellen extern joinen (zum Beispiel über Spark oder Trino). Jetzt geht alles direkt in R2:

• INNER JOIN — Standard-Inner-Join,
• LEFT JOIN und RIGHT JOIN — One-Sided-Lookups,
• FULL OUTER JOIN — beide Seiten erhalten,
• CROSS JOIN — kartesisches Produkt,
• Implicit Joins über WHERE-Klauseln,
• Subqueries in WHERE, SELECT und FROM,
• Multi-Table-CTEs — WITH-Clauses mit mehreren Tabellen-Refs.

Heisst: Du kannst deine Order-Tabelle mit der Customer-Tabelle joinen, dann das Ergebnis per CTE mit den Returns abgleichen — alles in einer Query, alles serverless, alles auf R2.

UNGLAUBLICH: Analytics-API obendrauf

Im selben Changelog kommt R2 Data Catalog Analytics via Cloudflares GraphQL Analytics API. Zwei neue Datasets stehen bereit:

• r2CatalogDataOperationsAdaptiveGroups — trackt Iceberg-REST-API-Requests (Operation-Typ, Request-Dauer, HTTP-Status, Body-Bytes).
• r2CatalogTableMaintenanceAdaptiveGroups — trackt Maintenance-Jobs wie Compaction und Snapshot-Expiration.

Wer R2-Lakes betreibt, sieht damit zum ersten Mal, was wirklich passiert: Welche Tabellen werden wie oft gelesen? Wo läuft Compaction zu lange? Welche Iceberg-Snapshots fressen Storage?

GEFAHR! Falsche Joins sprengen DEINE Workers-Rechnung

JOINs sind mächtig — aber auch teuer. Wer aus Versehen ein CROSS JOIN auf zwei Millionen-Zeilen-Tabellen ansetzt, produziert zwei Billionen Zeilen Output. R2 SQL läuft serverless, also wird jede CPU-Sekunde berechnet. Cloudflare empfiehlt explicit:

• EXPLAIN vor jedem komplexen Join verwenden,
• Indizes (Iceberg-Partition-Specs) zuerst optimieren,
• Subqueries auf kleinste Filter-Ergebnisse einschränken,
• Limits in der Entwicklung setzen (LIMIT 1000), bevor Production-Loads laufen.

So baust du deinen ersten Multi-Table-Query in 5 MINUTEN

1. Im Cloudflare-Dashboard → R2 → Data Catalog → SQL-Editor öffnen.
2. Zwei Iceberg-Tabellen anlegen oder existierende auswählen.
3. Beispiel-Query:

   SELECT c.name, SUM(o.amount) AS total
   FROM customers c
   LEFT JOIN orders o ON c.id = o.customer_id
   WHERE o.created_at >= DATE '2026-01-01'
   GROUP BY c.name
   ORDER BY total DESC
   LIMIT 50;

4. Run drücken — Ergebnisse erscheinen direkt im Dashboard.
5. Für Production: Worker mit R2 SQL Binding bauen, der den Query via API ausführt.

EXTRA-TIPP: Kombiniere mit Workers KV für Caching

Cloudflare hat parallel die Workers-KV-Cache-TTL-Mindestzeit von 60 auf 30 Sekunden reduziert. Damit lässt sich ein typischer Read-Heavy-Workflow super absichern: R2-SQL-Query → Worker → KV-Cache für 30s. Schnelle Reads, geringe R2-Kosten, hohe Aktualität.

FAZIT: R2 wird zur ernsten Lakehouse-Plattform

Cloudflare hat mit R2 + Iceberg + SQL + Analytics-API einen kompletten Open-Lakehouse-Stack zusammengebaut, der mit Snowflake und Databricks konkurriert — Egress-frei und serverless. Wer 2026 ein neues Daten-Backend baut, sollte R2 mindestens in den PoC packen.

Quellen

• Cloudflare Developer Changelog
• Cloudflare R2 SQL Documentation
• Cloudflare What’s New