DuckDB 2.0 dimostra perché l’analisi va tenuta vicino ai dati

Per anni il cloud ci ha convinti che l’analisi seria dei dati dovesse avvenire nel data center di qualcun altro. DuckDB 2.0 arriva con una proposta più interessante: forse l’architettura più intelligente non è scegliere tra cloud e locale, ma capire quali operazioni non dovrebbero mai lasciare il dispositivo.

Rilasciato il 21 ottobre 2026, DuckDB 2.0.0 LTS, nome in codice “Cinnamon Teal”, è finora la versione del progetto con il maggior numero di novità. Include un protocollo Quack completo e rifinito, I/O asincrono, un tipo VARIANT nativo, la modalità agent, i trigger e un parser SQL estensibile, sviluppati a partire da quasi 20.000 commit dall’uscita di DuckDB 1.5, secondo il progetto DuckDB. La linea LTS è supportata almeno fino a ottobre 2027.

L’elenco delle funzionalità conta meno della direzione che lo guida. DuckDB è nato come database analitico in-process: SQL eseguito all’interno di un’applicazione, di un laptop o di un dispositivo edge, invece che tramite un servizio di database sempre attivo. La versione 2.0 amplia questo modello senza abbandonarlo. A nostro avviso, è questa la vera notizia.

DuckDB 2.0 considera il cloud una risorsa, non la destinazione predefinita

L’aggiunta più rivelatrice è Quack. Ora DuckDB può fornire database attraverso la rete, mentre un altro client DuckDB può collegarsi e indirizzare le query in remoto usando la nuova istruzione CONNECT. Sembra un normale database client-server, ma la differenza fondamentale è che entrambi i lati restano istanze DuckDB complete. Il client può continuare a eseguire calcoli localmente.

È una risposta più sfumata all’architettura cloud rispetto alla semplice costruzione di un servizio ospitato più grande. Un laptop può esaminare o trasformare i dati localmente, un database remoto può gestire le informazioni centralizzate e il confine tra i due può essere scelto query per query. Lo stesso meccanismo CONNECT può funzionare anche con PostgreSQL e MySQL, mentre un ottimizzatore per il pushdown remoto invia le query compatibili a quei server invece di trasferire intere tabelle attraverso la rete.

Questa flessibilità è preziosa perché lo spostamento dei dati rappresenta spesso il costo nascosto dell’analisi. Inviare tutto a un data warehouse aumenta la dipendenza dalla connettività, aggiunge latenza e può esporre inutilmente dati sensibili. Tenere tutto in locale, però, può rendere più difficili la collaborazione, la governance e la scalabilità centralizzata. La direzione di DuckDB 2.0 suggerisce un compromesso pratico: spostare i calcoli quando è utile, non perché l’architettura lo dia per scontato.

La descrizione del progetto è insolitamente chiara su questo punto: DuckDB può funzionare ovunque, dai dispositivi edge ai server con centinaia di core, e può lavorare con file locali o object storage. La pagina della piattaforma DuckDB presenta questa portabilità come una proprietà fondamentale, non come un’aggiunta dell’ultimo minuto.

La funzionalità cloud più importante è quella che fa sembrare locali i dati remoti

L’I/O asincrono può sembrare meno affascinante di un nuovo protocollo o di una modalità CLI orientata all’IA, ma probabilmente è la funzionalità con il vantaggio pratico più evidente per i carichi di lavoro che fanno ampio uso del cloud. DuckDB 2.0 separa le letture remote dall’elaborazione delle query, consentendo di mantenere più richieste in corso mentre la CPU lavora sui dati già disponibili.

Questa progettazione è pensata per file Parquet e CSV nell’object storage, come S3. Un’analisi di MotherDuck descrive letture da S3 da 2 a 3 volte più veloci nello scenario di test, senza modificare le query; quei risultati sono stati ottenuti con un solo laptop e una connessione Internet domestica, quindi vanno considerati un esperimento indicativo, non un benchmark universale. L’analisi di MotherDuck illustra comunque il punto più ampio: l’esecuzione locale non significa ignorare il cloud. Può voler dire usare il cloud come spazio di archiviazione, evitando però una deviazione analitica più pesante.

È qui che il modello di DuckDB diventa convincente. Un data warehouse resta utile quando molti utenti hanno bisogno di analisi condivise, governate e aggiornate di continuo. Ma per uno sviluppatore che sta esplorando un dataset, per un’applicazione che genera un report o per un sistema edge che filtra gli eventi prima del caricamento, pagare il costo di un cluster remoto per ogni domanda appare sempre più eccessivo. L’unità giusta da ottimizzare non è sempre il data center. A volte è il viaggio di andata e ritorno.

VARIANT rende l’analisi embedded più adatta ai dati disordinati

I sistemi di analisi locali sono stati tradizionalmente più interessanti quando i dati erano già ordinati. Le applicazioni reali collaborano meno. I log cambiano, i payload degli eventi assumono forme diverse e spesso i team devono interrogare record semistrutturati prima che qualcuno abbia progettato uno schema perfetto.

Il tipo VARIANT di DuckDB 2.0 affronta questo problema memorizzando dati tipizzati e privi di schema, mantenendo al tempo stesso l’esecuzione colonnare. Il motore può rilevare le strutture comuni e “scomporle”, così i campi ricorrenti vengono compressi ed eseguiti in modo più simile alle normali colonne. È un miglioramento significativo rispetto al trattare ogni documento JSON come testo, soprattutto per log e flussi di eventi la cui struttura è in parte stabile e in parte imprevedibile.

La precisazione è altrettanto importante: non è magia. I dati con tipi di valore incoerenti non otterranno gli stessi vantaggi dei campi strutturati in modo uniforme. DuckDB sta rendendo più efficace l’analisi locale flessibile, non sta eliminando la necessità di modellare i dati. È un punto di forza, non una debolezza. Gli strumenti migliori dovrebbero ridurre il costo dei dati imperfetti senza fingere che la qualità dei dati non conti più.

Lo stato LTS conta perché gli strumenti locali hanno bisogno di continuità

Il software embedded è facile da adottare e facile da abbandonare. Uno sviluppatore può inserire rapidamente una libreria in un’applicazione, ma i sistemi di produzione hanno bisogno di manutenzione prevedibile, percorsi di migrazione e stabilità sufficiente a giustificare la costruzione di un progetto intorno a quel componente.

Lo stato LTS di DuckDB 2.0 conta quindi anche oltre la data di fine del supporto. Il progetto afferma che la versione 2.0 riceverà supporto almeno fino a ottobre 2027, mentre la precedente linea 1.4 LTS resterà supportata almeno fino alla fine di novembre 2026 e DuckDB 1.5 è stata estesa fino a marzo 2027. Questa sovrapposizione lascia ai team il tempo di fare test, invece di trasformare un aggiornamento importante in un’emergenza.

C’è anche un segnale strategico. DuckDB sta aggiungendo connettività ai server, osservabilità e un comportamento della riga di comando più adatto agli agenti, senza rinunciare alla propria identità di motore in-process. Il risultato non è un sostituto del cloud data warehouse, e non dovrebbe essere presentato come tale. È un modo per rendere l’analisi più componibile: oggi dentro un laptop, domani dentro un’applicazione e collegata all’infrastruttura centralizzata quando il carico di lavoro lo richiede davvero.

Il nostro giudizio è semplice: vale la pena tenere d’occhio DuckDB 2.0 non perché renda l’analisi locale universalmente superiore, ma perché rende più difficile liquidare l’architettura ibrida. I team dovrebbero mantenere i data warehouse centralizzati per la scalabilità condivisa e la governance, valutando seriamente DuckDB per l’esplorazione, i report embedded, l’elaborazione edge e le analisi sensibili sotto il profilo della privacy. Il futuro dell’elaborazione dei dati probabilmente non sarà fatto di cluster più grandi ovunque. Sarà fatto di decisioni migliori su dove eseguire ogni query.