Non è un’acquisizione miliardaria e AWS non ne ha comunicato il valore, ma l’ingresso di DuckLabs in Amazon Web Services riguarda una tecnologia che sta modificando il modo in cui una parte dell’analytics viene inserita nelle applicazioni e nelle pipeline data.
Il 26 agosto AWS ha annunciato l’accordo per acquisire la società di Amsterdam fondata da Hannes Mühleisen e Mark Raasveldt, i creatori di DuckDB; DuckLabs ha successivamente confermato che l’operazione si è conclusa il 31 agosto e che il team è entrato in AWS dal 1° settembre 2026.
DuckDB appartiene a una generazione di strumenti che sfruttano la crescente capacità dei computer e dei server moderni per eseguire localmente elaborazioni che in precedenza sarebbero state affidate quasi automaticamente a un’infrastruttura dedicata. Nel suo caso, questa impostazione assume la forma di un database analitico completo che può essere incorporato direttamente nel software e lavorare sui dati nel luogo in cui già si trovano.
Un motore OLAP dentro l’applicazione
DuckDB è un database relazionale OLAP, Online Analytical Processing, embedded e in-process, progettato per aggregazioni, join, scansioni e altre operazioni analitiche su grandi quantità di dati.
La differenza rispetto all’architettura database più comune riguarda il deployment. Con PostgreSQL, MySQL o molti sistemi analitici, l’applicazione comunica con un processo server distinto; DuckDB viene invece caricato come libreria nello stesso processo del software che lo utilizza.
Un notebook Python può quindi importarlo ed eseguire immediatamente query SQL, mentre un’applicazione può incorporare il motore senza dover installare e amministrare un servizio database autonomo.
Il database può essere persistente oppure funzionare in memoria e supporta elaborazioni larger-than-memory, ricorrendo allo storage temporaneo quando il workload supera la RAM disponibile. Il motore è inoltre colonnare e vettorializzato, quindi elabora blocchi di valori e risulta particolarmente adatto alle query che devono scansionare molte righe, utilizzare poche colonne, effettuare aggregazioni o collegare dataset.
È questa combinazione fra modello embedded e architettura OLAP a caratterizzare DuckDB rispetto ai tradizionali database incorporati nelle applicazioni.
Dalla ricerca sui database a tre milioni di download al giorno
DuckDB nasce al Centrum Wiskunde & Informatica (CWI) di Amsterdam, dove Mühleisen e Raasveldt lavoravano sull’architettura dei database. Una delle premesse del progetto era che la potenza disponibile sui computer personali stesse crescendo molto più rapidamente della capacità del software analitico di sfruttarla con semplicità.
DuckLabs venne fondata nel 2021 per dare una struttura stabile al gruppo di sviluppo e seguì un percorso poco comune tra le società nate intorno a progetti open source: rimase bootstrapped, posseduta dai fondatori e dal team e senza venture capital, nonostante l’interesse degli investitori.
La crescita di DuckDB ha però cambiato le dimensioni del problema. DuckLabs conta poco più di 30 persone, mentre dichiara ormai oltre tre milioni di download quotidiani del database. Mühleisen e Raasveldt spiegano che continuare autonomamente avrebbe richiesto di costruire una struttura molto più grande per vendite, supporto e operations, rischiando di spostare energie dallo sviluppo tecnologico.
L’ingresso in AWS offre invece distribuzione globale, infrastruttura e accesso a una base molto più ampia di sviluppatori e aziende. L’obiettivo indicato dai fondatori è che DuckDB, DuckLake e Quack possano essere utilizzati anche da persone che non conoscono direttamente queste tecnologie, funzionando “quietly inside the products and services they use”.
CSV, Parquet e JSON possono restare dove sono
Un’altra caratteristica importante di DuckDB è la possibilità di interrogare direttamente i formati utilizzati nelle pipeline data, senza dover necessariamente importarli in tabelle proprietarie.
Un file Apache Parquet può essere utilizzato direttamente in una query SQL e lo stesso vale per CSV e JSON; attraverso il sistema di estensioni, il motore può inoltre accedere ad altre sorgenti.
Con un semplice CSV bastano poche righe di Python:
import duckdb
result = duckdb.sql("""
SELECT city, AVG(temperature) AS avg_temperature
FROM 'weather.csv'
GROUP BY city
ORDER BY avg_temperature DESC
""")
print(result)weather.csv diventa direttamente la sorgente della query, senza creazione preventiva di una tabella.
La stessa operazione con Pandas può essere scritta così:
import pandas as pd
df = pd.read_csv("weather.csv")
result = (
df.groupby("city", as_index=False)["temperature"]
.mean()
.rename(columns={"temperature": "avg_temperature"})
.sort_values("avg_temperature", ascending=False)
)
print(result)Il risultato è equivalente, ma il modello è differente. Pandas carica il CSV in un DataFrame e applica le trasformazioni attraverso le API Python; DuckDB lascia che sia il motore SQL, con il proprio optimizer, a pianificare lettura, aggregazione e ordinamento.
Quando prevalgono trasformazioni relazionali, join e query complesse, DuckDB può quindi risultare più naturale e gestire dataset che eccedono la memoria disponibile; Pandas rimane più flessibile nei workflow strettamente legati a funzioni Python, librerie scientifiche, visualizzazione e machine learning. I due strumenti possono anche convivere, utilizzando DuckDB per la preparazione dei dati e Pandas per le elaborazioni successive.
Con Parquet il motore sfrutta inoltre projection pushdown e filter pushdown, evitando di leggere colonne e porzioni del dataset non necessarie alla query.
I file possono trovarsi localmente oppure su object storage accessibile via HTTP e S3, mentre le estensioni per PostgreSQL e MySQL consentono di combinare dati provenienti da database operativi con file esterni all’interno della stessa elaborazione.
Dal laptop alle pipeline data
Per un data analyst, DuckDB consente di aprire file CSV o Parquet e iniziare a interrogarli in SQL; per un data scientist, l’integrazione con Python, Pandas e Apache Arrow permette di inserirlo nei notebook e nei workflow di machine learning.
Nel data engineering può invece svolgere il ruolo di motore di trasformazione, leggendo dataset da object storage e producendo, per esempio, nuovi file Parquet, mentre gli sviluppatori possono incorporare capacità analitiche SQL direttamente nei propri prodotti.
Un’indagine condotta dal progetto nel 2024 su oltre 500 utilizzatori mostrava già questa varietà: l’87% utilizzava DuckDB su laptop e il 58% anche su server, mentre Python, indicato dal 73%, risultava l’interfaccia più diffusa. Fra i principali profili professionali figuravano data engineer, analyst, data scientist e software engineer.
Con chi si confronta DuckDB
DuckDB incrocia categorie differenti e non ha quindi un unico concorrente diretto.
| Tecnologia | Ambito principale | Differenza rispetto a DuckDB |
|---|---|---|
| SQLite | Database embedded transazionale | Condivide il deployment embedded, ma è orientato soprattutto all’OLTP |
| ClickHouse | Analytics OLAP real-time | È un database server distribuito, pensato anche per ingestione continua e alta concorrenza |
| Snowflake / BigQuery / Redshift / Databricks | Analytics cloud e lakehouse | Comprendono elaborazione distribuita, governance, multiutenza e servizi di piattaforma |
| Pandas / Polars | Data processing | Utilizzano principalmente il modello DataFrame anziché quello di un DBMS SQL |
| Apache DataFusion | Query engine embedded | È soprattutto un componente per costruire altri sistemi analitici |
SQLite è il riferimento più vicino dal punto di vista operativo, ma è progettato principalmente per workload transazionali. ClickHouse condivide invece l’orientamento OLAP, ma nasce come database server e può distribuire dati e calcolo su più nodi.
Snowflake, BigQuery, Redshift e Databricks affrontano una parte degli stessi problemi all’interno di piattaforme molto più ampie, mentre con Pandas, Polars e Apache DataFusion la sovrapposizione riguarda soprattutto l’elaborazione inserita direttamente nel codice e nelle pipeline.
MotherDuck e il modello DuckDB nel cloud
Tra DuckDB locale e le grandi piattaforme distribuite si colloca MotherDuck, società indipendente da DuckLabs e dalla DuckDB Foundation che utilizza lo stesso motore associandolo a storage e capacità computazionale serverless.
Il suo hybrid query processing permette di suddividere l’elaborazione tra computer locale e cloud, mantenendo quindi l’ambiente DuckDB anche quando servono condivisione dei dati o risorse aggiuntive.
DuckLake e Quack oltre il database embedded
L’ecosistema si è nel frattempo ampliato oltre il database originario.
DuckLake affronta il modello lakehouse mantenendo i dati su object storage e utilizzando un database SQL per gestirne i metadati; Quack consente invece alle istanze DuckDB di comunicare via HTTP, aggiungendo accesso remoto.
Insieme a DuckDB formano quello che DuckLabs chiama Duck Stack, con il database analitico al centro di un insieme più ampio di tecnologie per accedere e lavorare su dati conservati in sistemi diversi.
Perché AWS ha acquisito DuckLabs
AWS possiede già una gamma estesa di servizi analytics: Amazon S3 per lo storage, Redshift per il data warehousing, Athena per le query serverless, EMR per l’elaborazione distribuita, Glue per integrazione e trasformazione dei dati e SageMaker per data science e machine learning. DuckDB aggiunge qualcosa di differente: un query engine molto compatto che AWS può incorporare direttamente nei propri servizi.
Nell’annuncio dell’acquisizione, AWS sostiene che oltre il 90% delle query sui dati riguarda spesso dataset dell’ordine di un terabyte o meno e descrive come scale-down la possibilità di affrontare questi workload sfruttando efficacemente le risorse di una singola macchina.
L’interesse è già concreto. Amazon Quick, precedentemente QuickSight, usa DuckDB per interrogare dati conservati in S3 Tables e, secondo AWS, dal lancio di Quick nell’ottobre 2025 il query engine del servizio, con le integrazioni e ottimizzazioni DuckDB, ha elaborato oltre 2,5 miliardi di query, contribuendo a ridurre del 30% la latenza media. DuckDB può inoltre essere utilizzato all’interno di AWS Lambda e operare direttamente sui dati conservati in S3.
AWS associa il motore anche ai workload AI agentici, nei quali gli agenti possono generare molte interrogazioni esplorative, esaminare risultati intermedi e modificare progressivamente la propria ricerca: un pattern nel quale un engine incorporato nel processo può evitare il ricorso a servizi analitici più complessi per ogni singola operazione.
La combinazione prospettata da AWS è quindi quella fra DuckDB per l’elaborazione più circoscritta e servizi come S3, Redshift, Athena, EMR, Glue e SageMaker quando aumentano dimensioni, concorrenza o requisiti operativi.
L’open source rimane alla DuckDB Foundation
AWS ha acquisito DuckLabs e il suo team, mentre la proprietà intellettuale dei progetti open source rimane alla DuckDB Foundation.
DuckDB, DuckLake, Quack e gli altri componenti continueranno a essere distribuiti con licenza MIT e la Foundation manterrà il proprio ruolo di stewardship. È prevista inoltre una maggiore partecipazione della comunità attraverso un technical advisory board e un’apertura del sistema delle estensioni verso componenti firmati da sviluppatori e organizzazioni esterne.
AWS ottiene quindi le competenze del gruppo che ha costruito DuckDB, senza acquisire la proprietà del progetto open source.
Un database piccolo dentro uno stack molto più grande
L’interesse per DuckDB nasce da una scelta architetturale precisa: utilizzare un motore specializzato e incorporabile quando il problema non richiede necessariamente una piattaforma analitica completa.
Con la crescita della capacità hardware, la diffusione dell’object storage e l’affermazione di formati aperti, questa possibilità riguarda ormai workload molto più consistenti di quelli tradizionalmente associati a un database embedded.
L’acquisizione di DuckLabs consente ad AWS di inserire questo motore direttamente nei propri prodotti, affiancandolo all’infrastruttura analytics distribuita già disponibile nel cloud.
