DuckDB per l'Analisi GIS: Quando Conviene e Come Si Usa

Analisi geospaziali in SQL con DuckDB e l'estensione spatial: GeoParquet, funzioni spaziali e il confronto con PostGIS, senza bisogno di un server.

Redazione Zornade
3 min di lettura
Immagine di copertina per: DuckDB per l'Analisi GIS: Quando Conviene e Come Si Usa

DuckDB è un database analitico che vive dentro il tuo processo, come una libreria: nessun server da installare, SQL completo, e prestazioni che su file Parquet raggiungono e spesso superano i motori distribuiti. Con l'estensione spatial diventa uno strumento geospaziale serio, capace di gestire milioni di geometrie in una query. È la risposta a un problema che chiunque abbia analizzato dati territoriali conosce: i file geografici grandi non entrano comodi in memoria, e i database classici sono macchina da guerra per uso saltuario.

L'estensione spatial

L'estensione si installa con un comando una tantum e porta con sé le funzioni spaziali: lettura e scrittura di GeoJSON, GeoParquet, shapefile, funzioni di misura, predicati, unioni spaziali e riproiezioni. La sintassi è SQL standard, quindi chi conosce PostGIS si trova a casa, con un modello mentale da adattare: DuckDB è orientato alle colonne e ai file, pensato per leggere e aggregare, non per aggiornare righe in transazioni concorrenti come un database operativo.

Quando conviene

Conviene quando il dato arriva come file, Parquet e GeoParquet in testa: la scansione è velocissima e il formato è compresso, quindi dataset che in GeoJSON pesano gigabyte diventano maneggevoli. Conviene per le analisi da ripetere su file che cambiano, dove un database tradizionale richiederebbe import continui. Conviene per chi non vuole gestire un'infrastruttura: lo script Python o R che fa l'analisi porta con sé il motore. Non conviene, o conviene meno, per i dati vivi serviti a più applicazioni contemporaneamente, dove PostGIS resta la scelta giusta, e per l'editing interattivo, che resta territorio del GIS desktop.

Come si usa in pratica

Il flusso tipico è: apri un file, filtri, aggreghi, esporti il risultato. Il primo comando legge il file e ne ispeziona lo schema; il secondo fa l'analisi, ad esempio un'unione spaziale tra punti e poligoni, che in DuckDB si scrive con un join su predicato spaziale; il terzo scrive il risultato in Parquet o GeoJSON per portarlo nel GIS o nel report. Il tutto in poche righe, con tempi che su file di milioni di righe si misurano in secondi su un portatile normale.

DuckDB e il resto del tuo stack

La cosa più utile da capire è che DuckDB non sostituisce niente: completa. I dati si tengono dove vivono, e DuckDB li interroga: file locali, oggetti su storage remoto, e anche PostGIS, perché DuckDB sa leggere tabelle Postgres direttamente. È il collante analitico tra i file che ricevi e le risposte che devi dare. Per chi fa analisi territoriali in Italia, il pattern vincente è ormai chiaro: i dati geografici pesanti si interrogano in SQL. Noi lo applichiamo su un database da 622 GB, con 85 milioni di particelle e una dozzina di tabelle di arricchimento da decine di milioni di righe l'una, e chi parte da particelle e geometrie catastali trova in Zornade il dato di base pronto per l'analisi, da unire a qualunque altro layer. Se il tuo caso è un pipeline su misura, i servizi di sviluppo software partono da una valutazione tecnica gratuita.

Foto di copertina: César Gaviria su Pexels

Stai usando questi dati per un progetto aziendale?

Possiamo costruire la soluzione completa per te - backend, frontend, data engineering, deploy e supporto. Prima valutazione tecnica gratuita.

Richiedi un preventivo gratuito