MimìrCast: le novità sull’AI ogni giorno Ascolta il podcast ➔
Perché DuckDB è così veloce architettura e ottimizzazioni spiegate

Perché DuckDB è così veloce: architettura e ottimizzazioni spiegate

DuckDB è un database OLAP in-process che esegue query analitiche fino a 10-100 volte più velocemente di Pandas o SQLite grazie a una combinazione precisa: storage colonnare, esecuzione vettorializzata a chunk di 1.024 valori e parallelizzazione automatica su tutti i core. Per chi costruisce pipeline AI, RAG o feature engineering, questa velocità si traduce in iterazioni più rapide e meno infrastruttura da gestire.

In questo articolo scoprirai:

  • Cos’è DuckDB e perché è rilevante per chi lavora con dati AI/ML
  • Come funzionano storage colonnare ed esecuzione vettorializzata
  • Le ottimizzazioni che gli permettono di battere i database tradizionali sulle query analitiche
  • I casi d’uso pratici per RAG, embedding e training di modelli
  • Le novità 2026: DuckDB 1.5 e DuckLake 1.0

Cos’è DuckDB e perché interessa chi lavora con dati AI

DuckDB è un sistema di gestione database SQL OLAP in-process, cioè un motore che gira dentro lo stesso processo dell’applicazione, senza server separato, concettualmente “lo SQLite dell’analytics”. Pensato nel 2018 al CWI di Amsterdam, è progettato per query analitiche su dataset di milioni o miliardi di righe direttamente da laptop, notebook Jupyter o pipeline Python.

Per un data scientist o un ML engineer, questa architettura risolve un problema concreto: caricare un CSV da 5 GB in Pandas spesso satura la RAM, mentre DuckDB legge lo stesso file in streaming, applica predicati e restituisce solo le colonne richieste. Secondo analisi pubblicate nel 2026, DuckDB sta progressivamente sostituendo Pandas per l’analisi su larga scala in molti workflow di data science.

Inoltre, DuckDB legge nativamente formati come Parquet, CSV, JSON e Arrow con interoperabilità zero-copy verso Pandas e Polars, il che significa che i dati non vengono duplicati in memoria quando si passa da un framework all’altro. Per chi gestisce embeddings o feature store, questa caratteristica è cruciale: si evita il collo di bottiglia della serializzazione tra processi diversi.

I pilastri architetturali che rendono DuckDB così veloce

La velocità di DuckDB poggia su quattro pilastri progettati per sfruttare al massimo le CPU moderne: storage colonnare, esecuzione vettorializzata, parallelizzazione automatica e gestione intelligente della cache CPU. Ognuno di questi attacca un collo di bottiglia diverso rispetto ai database row-oriented tradizionali.

Lo storage colonnare significa che ogni colonna è salvata separatamente: una query che chiede SELECT AVG(price) FROM sales legge solo la colonna price, ignorando le altre. Questo riduce drasticamente l’I/O su dataset analitici, dove tipicamente si scansionano milioni di righe ma solo poche colonne. Come spiegato nel technical deep-dive di Endjin, questo layout abilita anche compressione molto più aggressiva, perché valori simili sono fisici-vicini.

La parallelizzazione automatica distribuisce il lavoro su tutti i core disponibili senza configurazione: DuckDB partiziona internamente i dati in “morsel” e li processa in pipeline parallele. Le zone maps, piccoli indici min/max per blocco, permettono di saltare interi segmenti di dati quando il predicato non li può soddisfare. Infine, quando il dataset eccede la RAM, DuckDB fa spill-to-disk trasparente, evitando crash su carichi grandi.

Come funziona l’esecuzione vettorializzata di DuckDB

L’esecuzione vettorializzata è il cuore della performance di DuckDB: invece di processare una riga alla volta (modello “tuple-at-a-time” tipico di PostgreSQL e MySQL), DuckDB elabora vettori di 1.024 valori per ogni operatore, mantenendoli nella cache L1/L2 della CPU. Questo riduce drasticamente l’overhead di chiamate funzione e sfrutta istruzioni SIMD (Single Instruction Multiple Data).

Il vantaggio è quantificabile. Una CPU moderna legge dalla cache L1 in ~1 ns, dalla L2 in ~3 ns, dalla RAM in ~100 ns. Mantenendo i dati di lavoro in cache, DuckDB opera a velocità “nanosecondo” anziché “microsecondo”. Come documentato da Carnegie Mellon University nel corso 15-721, questo approccio, ispirato ai paper accademici su MonetDB/X100, è ciò che permette a DuckDB di rivaleggiare con sistemi MPP commerciali su singolo nodo.

SIMD e cache-friendliness: il dettaglio implementativo

Le moderne CPU x86 e ARM espongono istruzioni SIMD (AVX2, AVX-512, NEON) capaci di sommare o moltiplicare 8 o 16 valori in un singolo ciclo di clock. DuckDB struttura i suoi operatori, filtri, aggregazioni, join, perché il compilatore C++ possa generare automaticamente queste istruzioni sui vettori. Il risultato: un SUM su un miliardo di valori finisce in secondi anziché minuti.

Questa filosofia ricorda quella adottata in altri sistemi ad alta performance, incluse pipeline numeriche basate su algebra lineare per Machine Learning: l’idea che la velocità nasca dall’allineamento tra il pattern di accesso ai dati e il modello di esecuzione hardware.

Perché DuckDB è utile per pipeline AI, ML e RAG

DuckDB è diventato uno strumento centrale per chi costruisce applicazioni AI grazie all’estensione VSS (Vector Similarity Search) che aggiunge ricerca per similarità vettoriale tramite indici HNSW (Hierarchical Navigable Small World). In pratica, lo stesso database che esegue le tue query SQL può ora indicizzare embedding e restituire i top-K vettori più simili, abilitando pipeline RAG senza dover gestire un servizio vettoriale separato.

L’estensione VSS supporta distanze coseno, euclidea e prodotto interno negativo, costruite sulla libreria usearch con benchmark competitivi. Per progetti piccoli o single-tenant, come una RAG personalizzata per utente, questa è un’alternativa pragmatica a sistemi più pesanti. Per workload di produzione su milioni di vettori condivisi, restano preferibili soluzioni dedicate come Qdrant per la similarità vettoriale, come abbiamo approfondito nell’articolo sulla differenza tra database vettoriali e tradizionali.

I casi d’uso concreti includono: feature engineering su dataset tabulari prima del training (join, aggregazioni, deduplicazione con SQL); creazione di indici di similarità per sistemi RAG a basso overhead; orchestrazione di pipeline ML con strumenti come modelli di intelligenza artificiale generativa che richiedono accesso rapido a dati strutturati. Alcune estensioni della community permettono persino di addestrare modelli direttamente in SQL, eliminando il passaggio export/import verso Python.

Le novità DuckDB nel 2026

Il 2026 ha portato due aggiornamenti importanti: DuckDB v1.5.2 rilasciato ad aprile e la disponibilità generale di DuckLake 1.0, un formato lakehouse production-ready. Insieme, ampliano l’uso di DuckDB da motore locale a componente di architetture dati distribuite.

DuckLake, annunciato sul blog ufficiale DuckDB, risolve un problema noto di Iceberg e Delta Lake: invece di disperdere metadati in migliaia di file JSON e Avro sull’object storage, DuckLake conserva tutti i metadati in un database SQL standard. Questo riduce drasticamente la latenza di catalog discovery e abilita transazioni multi-tabella reali. La versione 1.0 supporta sorted tables, bucket partitioning, data inlining, tipi geometrici e deletion vector compatibili con Iceberg.

La versione LTS 1.4.2, annunciata a novembre 2025, ha consolidato la roadmap: DuckDB ora pubblica una versione LTS ogni due release, con supporto community di un anno. L’estensione Iceberg ha ricevuto pieno supporto DML (INSERT/UPDATE/DELETE), trasformando DuckDB in un client di lettura/scrittura completo verso data lake esistenti.

Come iniziare a usare DuckDB in un workflow AI

Il modo più rapido per provare DuckDB in un contesto AI è installarlo via pip install duckdb e attaccarlo a un notebook Jupyter o a uno script Python. Da lì si possono interrogare file Parquet, CSV o DataFrame Pandas con SQL standard, senza configurare server o gestire schema. Per chi parte da zero, l’official documentation contiene esempi pronti per pipeline analitiche.

Per un caso d’uso AI tipico, ad esempio costruire un indice di similarità su un corpus di documenti aziendali, il flusso è: caricare i testi in una tabella DuckDB, generare embedding via API (OpenAI, Cohere, modelli locali), salvarli come colonna FLOAT[] di dimensione fissa, creare un indice HNSW con l’estensione VSS, e infine eseguire SELECT ... ORDER BY array_cosine_distance(...). Tutto in poche righe di codice, senza infrastruttura esterna. Per integrazioni più complesse, vale la pena valutare come DuckDB si combina con framework come Cheshire Cat AI o con orchestratori basati su MCP Server.

Una raccomandazione pratica: DuckDB brilla su singolo nodo fino a centinaia di GB. Sopra il TB o per workload concorrenti multi-utente, conviene considerare soluzioni gestite come MotherDuck (il cloud commerciale costruito su DuckDB) o un classico data warehouse distribuito. La scelta dipende dal tradeoff tra semplicità e scala.

L’AI deterministica

L’efficienza analitica di DuckDB rappresenta un tassello fondamentale nell’evoluzione dei sistemi di Intelligenza Artificiale basati su RAG (Retrieval-Augmented Generation), come Mimír AI Agent.

In ambito enterprise oggi, infatti, la priorità è la transizione verso un’AI di tipo deterministico: l’integrazione della RAG permette infatti di ancorare le risposte a fonti dati certe, riducendo drasticamente le allucinazioni e garantendo un controllo rigoroso sulla sicurezza delle informazioni.

Il risultato è un sistema dove la potenza del calcolo vettoriale incontra la necessità di una governance del dato sicura, trasformando l’AI in un consulente aziendale affidabile e preciso.

Se vuoi scoprire come un sistema di Agenti AI può aiutarti a rendere scalabile il tuo business, registrati subito alla piattaforma o richiedi una demo gratuita personalizzata per le tue esigenze.

Fonti:

Tabella dei contenuti
Articoli correlati:
Vuoi che l'AI diventi il tuo motore di valore più potente?

Ti accompagniamo noi con Mimír AI Agent.