DuckDB 2.0 ora funziona anche come server. Ecco quando cambia il tuo stack, e quando no.

DuckDB ha rilasciato la versione 2.0.0 il 21 ottobre, la release più importante nella storia del progetto e l'inizio di una nuova linea di supporto a lungo termine, denominata in codice «Cinnamon Teal». Il titolo principale: DuckDB, un database in-process fin dal primo giorno, ora può funzionare come server. Una versione semplificata del suo protocollo Quack permette a un singolo processo DuckDB di servire i propri database sulla rete, e una nuova istruzione CONNECT consente a un'altra sessione di collegarsi e instradare le query. Lo strumento da riga di comando ha acquisito i comandi rapidi -serve e -connect per la stessa funzione. CONNECT funziona anche con PostgreSQL e MySQL, dove un nuovo ottimizzatore di pushdown invia la query al server remoto invece di trascinare intere tabelle attraverso la rete.

C'è molto altro. L'I/O asincrono rende le letture da S3 e altri archivi di oggetti molto più veloci. Un tipo VARIANT di prima classe gestisce i dati semi-strutturati. Ci sono trigger, un parser SQL basato su PEG a cui le estensioni possono aggiungere sintassi, e un nuovo formato di archiviazione predefinito. Il tutto proviene da quasi 20.000 commit dal DuckDB 1.5.

La modalità server è opzionale. Trattala come tale.

Il fascino di DuckDB stava nel fatto che non c'era nessun server da gestire. Lo si incorporava, lo si puntava su alcuni file Parquet o CSV, e si otteneva l'analisi colonnare all'interno del proprio processo. La modalità server 2.0 non cambia questo default, e la maggior parte dei team non dovrebbe adottarla sin dal primo giorno. Il motore embedded è ancora lo strumento giusto per la grande maggioranza dei carichi di lavoro analitici. La modalità di rete è per il caso specifico in cui più client devono genuinamente condividere un'unica istanza attiva.

Dal nostro lavoro di sviluppo con PHP e Docker su app ad alta intensità di dati, abbiamo visto team allestire una replica Postgres separata, o un intero warehouse, per supportare una schermata di report che in realtà interrogava solo una manciata di file. DuckDB embedded avrebbe fatto quel lavoro senza infrastrutture aggiuntive da gestire o aggiornare. Il nuovo I/O asincrono è il miglioramento silenzioso di questa release. Rende la versione di quel pattern basata su S3 abbastanza veloce da far sì che il reporting di medie dimensioni non necessiti più di un proprio server database. Se si sviluppano app cloud-native su AWS, questo elimina un componente variabile.

Anche il modello in-process funziona bene in mobilità. Nei nostri progetti nativi iOS e Android, specialmente nelle app offline-first in ambito sanitario e IoT, l'analisi sul dispositivo di solito significa scrivere manualmente query su SQLite o inviare i dati a un backend per l'elaborazione. Un motore analitico che gira all'interno dell'app, offline, si adatta meglio a quel lavoro di entrambe le opzioni. È il tipo di scelta architetturale che facciamo spesso nel nostro lavoro con i clienti.

Dove procederei con cautela: esporre Quack

La modalità server è la parte che mi preoccupa. Per impostazione predefinita il server Quack ascolta solo su localhost, che è la scelta giusta. La documentazione è chiara che l'opzione allow_other_hostname, quella che lo espone direttamente, è «destinata solo ai test». Se si vuole un accesso remoto reale, mantenere il server su localhost e mettere un reverse proxy con terminazione TLS davanti. Durante i nostri lavori di pentesting questo è uno dei modi più comuni in cui un servizio viene compromesso: viene distribuito con un'impostazione predefinita sicura, qualcuno modifica un'impostazione comoda per far funzionare una demo, e il servizio finisce non autenticato su un IP pubblico. Trattare una porta Quack come qualsiasi altra porta di database. Usare il token, terminare TLS a un proxy, e non esporla mai direttamente a internet.

La trappola dell'aggiornamento è il formato di archiviazione

Il breaking change che farà più danni è il formato di archiviazione. Per impostazione predefinita, la 2.0 scrive un nuovo formato che le versioni DuckDB precedenti alla 2.0 non possono leggere. La direzione opposta va bene. La versione 2.0 legge e scrive i file esistenti, e questi rimangono leggibili dalle versioni precedenti. Il problema sono i parchi macchine misti. Nel momento in cui un processo 2.0 crea o riscrive un database nel nuovo formato, ogni vecchio DuckDB che tocca quel file fallisce con un errore di versione. Se si gestiscono molti processi DuckDB con versioni diverse, questo è un problema di coordinamento, non un semplice aggiornamento di una riga.

Quindi prima di aggiornare qualsiasi cosa, verificare da dove vengono letti i file DuckDB e da quali versioni. Se due servizi condividono un file e solo uno passa alla 2.0, la prima scrittura dal lato aggiornato rompe l'altro in produzione. Fissare le versioni DuckDB nei Dockerfile e nei lockfile, aggiornare i writer per ultimi, e mantenere un fallback sulla vecchia linea durante i test. Il team DuckDB suggerisce di provare la 2.0 su un sistema shadow prima e dice che i carichi di lavoro mission-critical dovrebbero aspettare la prima patch, prevista a novembre. È un consiglio saggio. Tenere d'occhio anche il calendario delle linee più vecchie: il supporto alla 1.4 termina il 17 novembre, e la 1.5 è stata estesa a marzo 2027 per dare alle persone il tempo di migrare.

Perché l'etichetta LTS è importante

Un'altra cosa da evidenziare per i team con auditor presenti. La versione 2.0 è una release LTS, supportata almeno fino a ottobre 2027. Per i nostri clienti enterprise svizzeri con requisiti di conformità, «supportato fino a una data precisa» è spesso la differenza tra una dipendenza che supera la revisione e una che non la supera. Questo è un motivo concreto per preferire la linea LTS rispetto all'inseguire ogni feature release.

Se integrare l'analisi in un prodotto senza dover allestire un intero warehouse, o mettere in sicurezza un nuovo servizio di dati prima del lancio, vi suona familiare, parliamone.