DuckDB : l'analytique embarquée qui monte

[khalilbenaz]

---

lede: DuckDB apporte l'analytique colonne vectorisée dans un binaire embarqué sans serveur, capable d'interroger Parquet, CSV et Postgres directement là où vivent vos données.
lede_en: DuckDB brings vectorized columnar analytics in a serverless embedded binary, able to query Parquet, CSV and Postgres directly where your data lives.
title_en: DuckDB: embedded analytics on the rise

SQLite, mais pour l'analytique

DuckDB se résume à une analogie efficace : c'est le SQLite de l'analytique. Un binaire embarqué, sans serveur, sans dépendance, qui tourne dans votre processus — mais optimisé pour les requêtes OLAP au lieu des transactions OLTP. Là où SQLite excelle sur « lire une ligne par sa clé », DuckDB excelle sur « agréger cent millions de lignes sur trois colonnes ».

La différence tient à l'architecture : DuckDB est colonne et vectorisé. Il stocke et traite les données par colonnes, en lots (vectors) qui exploitent le cache CPU et les instructions SIMD. Pour une requête analytique, c'est un ordre de grandeur de différence avec un moteur ligne à ligne.

• Embarqué — pip install duckdb, import duckdb, et c'est parti. Pas de serveur.
• Colonne + vectorisé — l'exécution est pensée pour scanner et agréger vite.
• Zéro configuration — pas de tuning de cluster, pas de daemon à surveiller.

Le vrai super-pouvoir : interroger là où vivent les données

L'atout qui fait basculer les ingénieurs data, ce n'est pas seulement la vitesse — c'est de pouvoir requêter des fichiers sans les charger d'abord.

-- Interroger un Parquet distant sans import préalable
SELECT region, sum(amount)
FROM 'https://example.com/sales/*.parquet'
GROUP BY region
ORDER BY 2 DESC;

-- Joindre un CSV local et une table Postgres distante
SELECT c.name, s.total
FROM read_csv('customers.csv') c
JOIN postgres_scan('host=db', 'public', 'sales') s USING (id);

DuckDB lit nativement Parquet, CSV, JSON, et se connecte à Postgres, S3 ou des fichiers Arrow en mémoire. Le paradigme s'inverse : au lieu de rapatrier les données vers le moteur, vous amenez le moteur aux données. Pour l'exploration ad hoc et les pipelines, c'est transformateur.

Où DuckDB brille

• Analyse locale de gros fichiers — un data scientist interroge 50 Go de Parquet sur son laptop sans monter un cluster.
• Transformations dans les pipelines — DuckDB comme moteur de transformation (l'approche « in-process ») remplace des étapes Spark pour des volumes modérés.
• Backend analytique embarqué — dans une application, il calcule des agrégations sur les données locales sans base externe.
• Intégration Python/Arrow — échange zéro-copie avec pandas et Polars via Arrow, sans sérialisation coûteuse.

Comparaison : DuckDB et les autres

Critère	DuckDB	Spark	ClickHouse	Postgres
Modèle	embarqué	cluster	serveur	serveur
Cible	OLAP mono-nœud	OLAP distribué	OLAP serveur	OLTP+
Setup	nul	lourd	moyen	moyen
Volume idéal	Go à quelques To	To à Po	To à Po	Go à To

Le positionnement est limpide : DuckDB gagne quand le volume tient sur une seule machine — ce qui, avec les serveurs modernes, couvre une immense majorité des besoins analytiques réels. Spark et ClickHouse gardent le terrain du distribué à très grande échelle.

Pièges et limites

• Mono-nœud — DuckDB ne scale pas horizontalement ; au-delà de ce qu'une grosse machine encaisse, changez d'outil.
• OLAP, pas OLTP — écritures concurrentes intensives et transactions à haut débit ne sont pas son terrain ; ne remplacez pas Postgres par lui pour du transactionnel.
• Concurrence d'écriture limitée — un seul processus écrivain sur un fichier de base ; pensez lecture analytique, pas multi-writers.
• Gestion mémoire — une requête mal cadrée sur des données énormes peut saturer la RAM ; surveillez le spilling disque.

Verdict

DuckDB est l'un des outils les plus enthousiasmants de l'écosystème data en 2026, précisément parce qu'il supprime une couche entière de complexité. Beaucoup d'équipes ont monté des clusters Spark pour des volumes qu'un seul nœud DuckDB traite en secondes. Mon conseil : avant de provisionner de l'analytique distribuée, demandez-vous si vos données tiennent sur une grosse machine. Si oui — et c'est souvent le cas — DuckDB vous fera gagner un temps et un coût considérables.

SQLite, but for analytics

DuckDB boils down to one effective analogy: it's the SQLite of analytics. An embedded, serverless, dependency-free binary that runs inside your process — but optimized for OLAP queries instead of OLTP transactions. Where SQLite excels at "read a row by its key," DuckDB excels at "aggregate a hundred million rows over three columns."

The difference lies in the architecture: DuckDB is columnar and vectorized. It stores and processes data by columns, in batches (vectors) that exploit the CPU cache and SIMD instructions. For an analytical query, that's an order-of-magnitude difference from a row-at-a-time engine.

• Embedded — pip install duckdb, import duckdb, and you're off. No server.
• Columnar + vectorized — execution is built to scan and aggregate fast.
• Zero configuration — no cluster tuning, no daemon to babysit.

The real superpower: query where the data lives

The feature that flips data engineers isn't just speed — it's being able to query files without loading them first.

-- Query a remote Parquet without prior import
SELECT region, sum(amount)
FROM 'https://example.com/sales/*.parquet'
GROUP BY region
ORDER BY 2 DESC;

-- Join a local CSV and a remote Postgres table
SELECT c.name, s.total
FROM read_csv('customers.csv') c
JOIN postgres_scan('host=db', 'public', 'sales') s USING (id);

DuckDB natively reads Parquet, CSV, JSON, and connects to Postgres, S3 or in-memory Arrow files. The paradigm inverts: instead of moving data to the engine, you bring the engine to the data. For ad-hoc exploration and pipelines, that's transformative.

Where DuckDB shines

• Local analysis of large files — a data scientist queries 50 GB of Parquet on a laptop without spinning up a cluster.
• Pipeline transformations — DuckDB as a transformation engine (the "in-process" approach) replaces Spark steps for moderate volumes.
• Embedded analytics backend — inside an application, it computes aggregations on local data without an external database.
• Python/Arrow integration — zero-copy exchange with pandas and Polars via Arrow, without costly serialization.

Comparison: DuckDB and the others

Criterion	DuckDB	Spark	ClickHouse	Postgres
Model	embedded	cluster	server	server
Target	single-node OLAP	distributed OLAP	server OLAP	OLTP+
Setup	none	heavy	medium	medium
Ideal volume	GB to a few TB	TB to PB	TB to PB	GB to TB

The positioning is crystal clear: DuckDB wins when the volume fits on a single machine — which, with modern servers, covers a vast majority of real analytical needs. Spark and ClickHouse keep the very-large-scale distributed ground.

Pitfalls and limits

• Single-node — DuckDB doesn't scale horizontally; beyond what one big machine handles, switch tools.
• OLAP, not OLTP — intensive concurrent writes and high-throughput transactions are not its turf; don't replace Postgres with it for transactional work.
• Limited write concurrency — a single writer process on a database file; think analytical reads, not multi-writers.
• Memory management — a poorly scoped query on huge data can saturate RAM; watch disk spilling.

Verdict

DuckDB is one of the most exciting tools in the data ecosystem in 2026, precisely because it removes an entire layer of complexity. Many teams stood up Spark clusters for volumes a single DuckDB node handles in seconds. My advice: before provisioning distributed analytics, ask whether your data fits on one big machine. If it does — and it often does — DuckDB will save you considerable time and cost.