Cos'è pg_duckdb
pg_duckdb è un'estensione open-source per PostgreSQL, rilasciata con licenza MIT, nata dalla collaborazione tra il team di DuckDB, Hydra e MotherDuck. Il suo scopo è semplice da spiegare e potente nelle conseguenze: incorporare il motore analitico di DuckDB — colonnare e vettorizzato — direttamente dentro il processo di PostgreSQL.
Il risultato è che lo stesso database che usate per gestire ordini, clienti, fatture e log applicativi può improvvisamente rispondere a query analitiche complesse (aggregazioni, raggruppamenti, medie, conteggi su milioni di righe) con tempi tipici dei database analitici dedicati, spesso da 2 a 10 volte più veloci rispetto al motore standard, senza cambiare una riga di applicazione.
Il problema che risolve: OLTP vs OLAP
Per capire perché pg_duckdb conta, serve una distinzione che molti founder e tecnici di PMI conoscono per esperienza dolorosa.
PostgreSQL è un database OLTP (Online Transaction Processing): è progettato per gestire migliaia di piccole operazioni transazionali al secondo — inserimenti, aggiornamenti, letture puntuali. I dati sono archiviati per riga (row-based), il che è perfetto quando devi recuperare o modificare un singolo record completo, come la scheda di un cliente.
Le query analitiche (OLAP, Online Analytical Processing) hanno esigenze opposte: devono scansionare milioni di righe ma leggere solo poche colonne, per calcolare somme, medie, conteggi per categoria. Su un motore row-based questo significa leggere dal disco montagne di dati inutili. È il motivo per cui la dashboard della direzione impiega 40 secondi a caricarsi mentre il resto dell'applicazione vola.
La soluzione tradizionale delle grandi aziende è il data warehouse: un secondo sistema (ClickHouse, Snowflake, BigQuery, Redshift) alimentato da pipeline ETL che copiano i dati da Postgres ogni ora o ogni notte. Funziona, ma per una PMI o un'agenzia significa: un secondo database da mantenere, pipeline da monitorare, dati mai aggiornati in tempo reale, costi ricorrenti e complessità che richiede un data engineer.
pg_duckdb cancella questa architettura per una vasta classe di casi d'uso.
Come funziona
Tecnicamente, pg_duckdb si installa come estensione di PostgreSQL e viene caricato all'avvio del server tramite shared_preload_libraries. Da quel momento convivono due motori di esecuzione:
- Il motore nativo di Postgres continua a gestire tutte le operazioni transazionali: INSERT, UPDATE, DELETE, letture puntuali. Nulla cambia per l'applicazione.
- Il motore DuckDB entra in gioco per le query analitiche, eseguendole con un'architettura colonnare vettorizzata: i dati vengono processati a blocchi, colonna per colonna, sfruttando le istruzioni vettoriali (SIMD) dei processori moderni.
Il controllo è nelle mani di chi scrive le query. Si può forzare l'esecuzione DuckDB per singola sessione o per singola query, oppure materializzare tabelle analitiche in formato colonnare:
CREATE EXTENSION pg_duckdb;
-- Esecuzione forzata via DuckDB per una query analitica
SET duckdb.force_execution = true;
SELECT categoria, count(*), avg(importo)
FROM ordini
GROUP BY categoria;
Una caratteristica particolarmente interessante è l'accesso diretto ai formati da data lake: pg_duckdb può leggere (e scrivere) file Parquet, tabelle Iceberg e Delta Lake direttamente da SQL, anche su storage a oggetti come S3. Questo apre scenari ibridi: unire in un'unica query i dati operativi freschi di Postgres con archivi storici su Parquet, senza caricarli nel database.
-- Join tra dati live in Postgres e storico su Parquet
SELECT o.cliente, sum(o.totale)
FROM ordini o
JOIN read_parquet('s3://archivio/ordini_2024.parquet') s
ON s.cliente_id = o.cliente_id
GROUP BY o.cliente;
A cosa serve in pratica: casi d'uso concreti
Per una PMI, un'agenzia o un SaaS italiano, gli scenari tipici sono:
Dashboard e reportistica operativa. Metriche commerciali, funnel di vendita, performance campagne, margini per linea di prodotto: query di aggregazione che oggi rallentano il database di produzione o richiedono copie notturne dei dati. Con pg_duckdb girano in tempo reale sui dati vivi.
Analisi su log e eventi. Chi raccoglie eventi applicativi, log di chiamate, telemetria o clickstream in tabelle Postgres che crescono di milioni di righe al mese, può finalmente interrogarli senza dover esportare tutto altrove.
SaaS multi-tenant con analytics in-app. Chi sviluppa software gestionali o piattaforme B2B può offrire ai clienti dashboard analitiche integrate, alimentate dallo stesso Postgres che gestisce l'applicazione, senza aggiungere un data warehouse allo stack.
Archiviazione intelligente. I dati storici possono essere esportati in Parquet su object storage economico e restare comunque interrogabili via SQL insieme ai dati recenti: un mini-lakehouse senza infrastruttura dedicata.
Perché conta per il mercato italiano
Il tessuto produttivo italiano è fatto di PMI e software house con team tecnici piccoli. Per queste realtà, ogni componente infrastrutturale aggiuntivo è un costo: non solo economico, ma di attenzione, manutenzione e competenze.
pg_duckdb segue la filosofia "one database, più motori": invece di moltiplicare i sistemi (Postgres per le transazioni, un warehouse per le analytics, magari un terzo sistema per la search), porta la capacità analitica dentro il database che l'azienda già sa gestire. Backup, repliche, permessi, monitoraggio: restano quelli di sempre.
C'è anche un tema di sovranità e semplicità dei dati: i dati non devono lasciare il database, non devono essere copiati verso servizi cloud esterni, non esistono duplicati disallineati da riconciliare. Per aziende attente a GDPR e residenza dei dati, eliminare una pipeline di sincronizzazione verso un warehouse esterno significa eliminare una superficie di rischio.
Infine, il segnale di maturità dell'ecosistema è forte: l'estensione è disponibile in anteprima pubblica su servizi cloud gestiti (ad esempio Azure Database for PostgreSQL), ha superato i 3.000 star su GitHub e oltre un milione di download, ed è citata sempre più spesso come risposta standard al problema "Postgres lento sulle analytics".
Limiti e avvertenze
Onestà divulgativa: pg_duckdb non è la bacchetta magica e non sostituisce un vero data warehouse in tutti i casi.
- Concorrenza sulle risorse. Il motore analitico gira dentro il processo Postgres: query OLAP molto pesanti consumano CPU e RAM dello stesso server che serve le transazioni. In produzione seria, la best practice è eseguirlo su una replica di lettura dedicata.
- Copertura dei tipi. I tipi di dati più comuni (numerici, testo, date, JSON) sono supportati; tipi specializzati come quelli geografici di PostGIS possono avere supporto parziale.
- Progetto giovane. L'API evolve rapidamente: prima di un rollout produttivo serve validazione in staging e un occhio alle release note.
- Managed non sempre compatibili. Non tutti i provider di Postgres gestito permettono di installare estensioni custom con preload: verificare prima di progettare l'architettura.
Dove trovarlo e come provarlo
Il codice è su GitHub all'indirizzo github.com/duckdb/pg_duckdb, licenza MIT, documentazione inclusa. Il modo più rapido per provarlo è l'immagine Docker ufficiale oppure i pacchetti apt per le principali distribuzioni:
# Installazione pacchetto (esempio Debian/Ubuntu, Postgres 17)
sudo apt install postgresql-17-pg-duckdb
# Abilitazione e riavvio
echo "shared_preload_libraries = 'pg_duckdb'" | sudo tee -a /etc/postgresql/17/main/conf.d/pgduckdb.conf
sudo systemctl restart postgresql
# Attivazione nel database
sudo -u postgres psql -d miodb -c "CREATE EXTENSION pg_duckdb;"
La prova più onesta è semplice: prendere la query di reporting più lenta del proprio sistema, eseguirla con e senza duckdb.force_execution, e misurare. È il tipo di tecnologia che si giudica con uno stopwatch, non con una brochure.