Cloudflare ha rinominato la sua Data Platform in Basin e l’ha portata in disponibilità generale. Il cambio di nome è la parte meno interessante: ingestion, catalogo e query SQL vengono messi nello stesso percorso, mentre i dati restano in tabelle Apache Iceberg sopra R2 e possono essere letti anche da motori esterni compatibili.
Basin è tre prodotti, non un database travestito
Basin Pipelines riceve eventi da HTTP, Workers o Logpush, può trasformarli con SQL e li scrive in R2 come JSON, Parquet oppure tabelle Iceberg. Basin Catalog, il precedente R2 Data Catalog, gestisce metadata e manutenzione delle tabelle Iceberg. Basin SQL, prima R2 SQL, è il motore distribuito serverless che interroga quelle tabelle.
Il catalogo espone l’interfaccia REST standard di Iceberg. Cloudflare documenta l’accesso con strumenti come PyIceberg, Spark e Snowflake. Il percorso “ingest con Cloudflare, interroga altrove” è quindi parte del modello, non un incidente tollerato.
Il lock-in più efficace non è quello scritto nel contratto. È quello che compare quando spostare i dati costa più che cambiare idea.
Apache Iceberg diventa il confine architetturale
Iceberg definisce metadata, snapshot, schema evolution e organizzazione logica dei file senza imporre un singolo motore di calcolo. In Basin i file stanno in R2; il catalogo mantiene le tabelle; il compute può cambiare. Se storage e query engine hanno lo stesso confine proprietario, cambiare uno dei due significa spesso migrare anche l’altro. Se il confine è un formato aperto, la sostituzione resta difficile, ma almeno è tecnicamente negoziabile.
Cloudflare aggiunge un incentivo economico preciso: R2 non applica costi di egress Internet. La portabilità quindi non è soltanto “puoi esportare i dati”; diventa “puoi farli leggere da un altro motore senza trasformare ogni query esterna in una tassa sul movimento”.
Serverless non vuol dire senza infrastruttura
Basin elimina la necessità di dimensionare cluster per il percorso standard. Pipelines scala l’ingestion, Catalog gestisce metadata e compaction, SQL distribuisce le query sui Workers. Per chi usa il servizio, la capacità viene acquistata a consumo invece che prenotata come infrastruttura.
Ma serverless continua a non significare gratis o senza decisioni. La tariffazione di Basin separa trasformazioni, delivery verso i sink, operazioni e compaction del catalogo e dati scansionati da SQL; storage e operazioni R2 restano costi distinti. Basin SQL fattura i dati compressi scansionati. Una tabella organizzata male continua quindi a essere una tabella organizzata male, anche se non esiste un cluster da amministrare.
Il catalogo deve fare manutenzione, non solo ricordare dove sono i file
Cloudflare descrive Basin Catalog come qualcosa di più di un registro di metadata. Con la crescita dei dataset, il servizio può compattare file e metadata e generare statistiche usate dal query planner. Basin SQL sfrutta queste informazioni per suddividere le query e distribuirle.
Un data lake aperto può degenerare facilmente in una discarica aperta. Scrivere Parquet o Iceberg su object storage è semplice; mantenerlo efficiente mentre aumentano eventi, snapshot e piccoli file è il lavoro vero. Il valore del servizio managed sta quindi meno nel formato e più nell’automazione della manutenzione intorno al formato.
Un formato aperto riduce il costo di uscita. Non elimina il costo di tenere in ordine ciò che hai deciso di conservare.
Basin e K2 raccontano la stessa strategia da due lati
Il lancio arriva insieme a K2, il log durevole di Cloudflare costruito sopra R2. I due prodotti risolvono problemi diversi, ma mostrano una direzione comune: usare object storage come strato durevole e spostare sopra di esso compute più effimero e specializzato.
K2 usa R2 per il log e separa la retention dal compute che riceve gli eventi. Basin usa R2 e Iceberg per separare le tabelle dal motore che le interroga. In entrambi i casi Cloudflare prova a trasformare lo storage a oggetti da destinazione finale a primitive architetturale.
La domanda giusta non è “sostituisce Snowflake?”
Ridurre Basin a una gara contro Snowflake, Databricks o Athena sarebbe prematuro. Quei sistemi hanno ecosistemi, governance, strumenti BI, integrazioni e maturità che non si confrontano con una tabella prezzi e tre endpoint.
La domanda più utile è diversa: per quali workload vale la pena rendere Iceberg il punto stabile e considerare il motore di query una scelta sostituibile? Log analytics, telemetria, clickstream e pipeline che già vivono vicino a Workers e R2 sono candidati naturali. Un data warehouse aziendale pieno di procedure, policy e integrazioni non si migra perché un nuovo motore costa meno per terabyte scansionato.
Il valore di Basin, almeno oggi, sta nel rendere questa scelta meno binaria. Puoi usare il percorso end-to-end di Cloudflare, ma il dato resta in un formato che altri strumenti sanno leggere. È un’idea architetturale sana: scegliere un servizio managed senza dover fingere che sarà l’ultimo servizio che useremo.
Domande frequenti
Che cos’è Cloudflare Basin?
Cloudflare Basin è la piattaforma dati serverless di Cloudflare, ora generalmente disponibile, che riunisce Pipelines per ingestion e trasformazioni, Catalog per tabelle Apache Iceberg e SQL per le query distribuite.
Dove vengono conservati i dati di Basin?
Basin usa Cloudflare R2 come object storage e può organizzare i dataset in tabelle Apache Iceberg. Il formato aperto permette anche a motori compatibili esterni di leggere gli stessi dati.
Basin elimina il lock-in cloud?
No. Riduce però una parte del costo di uscita perché i dati possono restare in un formato aperto e R2 non applica costi di egress Internet. Restano dipendenze operative, integrazioni e costi dei servizi utilizzati.
Basin sostituisce Snowflake o Databricks?
Non automaticamente. Basin è particolarmente naturale per telemetria, log analytics, clickstream e workload vicini a Workers e R2; piattaforme data warehouse mature hanno ecosistemi, governance e integrazioni che vanno valutati caso per caso.