DuckDB et MotherDuck tuent le théâtre de l’entrepôt

DuckDB s’exécute en processus, MotherDuck propulse le même noyau SQL dans le cloud. Pour les équipes SaaS et Analytics, cela signifie : moins de théâtre autour des data warehouses, plus de requêtes hybrides, du laptop au mini-warehouse multi-locataire.

Les points clés en bref

En lien :Iceberg a remporté la guerre des formats. Maintenant, le catalogue compte  /  SAP vers BigQuery : un pont de données aux conséquences architecturales

Pourquoi le modèle warehouse par défaut semble trop coûteux en 2026

Dans le même temps, la pression monte pour intégrer l’analytics directement dans les produits. Graphiques orientés clients, rapports in-app, outils agents sur des données métiers : tout cela doit être rapide et isolé. Un warehouse centralisé peut le faire. Mais il n’est pas nécessaire pour chaque ligne de données.

De nombreuses équipes paient du compute inactif pour des dashboards qui s’exécutent trois fois par jour. Le modèle classique des data warehouses cloud scale horizontalement et facture en réservations. DuckDB inverse cette logique : le moteur se trouve là où les données résident déjà, dans le notebook, le service ou le job CI.

MotherDuck construit là-dessus la voie cloud. Le traitement hybride des requêtes décide quelle partie s’exécute en local et quelle partie dans le cloud. Pour les équipes data qui mélangent des fichiers Parquet sur un object storage et des échantillons locaux, cela évite les allers-retours constants vers le grand warehouse.

Quand le local suffit et quand le cloud s’impose

DuckDB local s’impose pour l’analyse interactive, les vérifications CI, les pipelines de features et l’analytics embarquée dans les produits. Ses limites concernent la concurrence, la gestion des utilisateurs et l’isolation multi-utilisateurs réelle. C’est précisément là que MotherDuck intervient : stockage managé, partage, isolation via des concepts d’hypertenancy et compute par utilisateur.

Pour l’analytics orientée clients, ce modèle est attractif. Au lieu d’un cluster multi-tenant bruyant, chaque client obtient un mini-warehouse isolé. Un cas d’usage Layers décrit comment un fournisseur SaaS a ainsi évité une hausse des coûts projetée de 100×. Ces cas sont proches des fournisseurs. Ils servent d’indicateur de tendance, pas de garantie pour votre workload.

L’ingestion agentique redéfinit le contrat d’exploitation

En juin 2026, SiliconANGLE rapportait que MotherDuck ajoutait une ingestion de données agentique : des agents doivent créer, planifier et maintenir des pipelines. Cela ressemble à un gain de productivité, mais introduit un nouveau mode de défaillance. Qui donne aux agents des droits d’écriture sur l’ingestion a besoin de garde-fous, de plafonds budgétaires et de revues comme pour tout autre bot de déploiement.

Concrètement, cela signifie : l’agent peut scanner les sources de staging et construire des propositions. Les écritures en production restent soumises à approbation. Les logs et la lignée doivent montrer quel agent a touché quelle table. Sinon, la « pile auto-construite » devient un cauchemar d’audit.

pg_duckdb mérite un regard particulier. Cette extension intègre le cœur de DuckDB dans Postgres et accélère les requêtes analytiques sans copier immédiatement les données dans un second système. Pour les équipes utilisant fortement OLTP-Postgres avec une charge analytique croissante, c’est souvent une entrée en douceur plutôt qu’un projet de data warehouse en big bang.

La gouvernance reste une obligation. Les autorisations de stockage d’objets, les équivalents de Row-Level Security et les logs d’audit doivent être aussi clairs dans le modèle hybride que dans un data warehouse classique. DuckDB rend le SQL rapide. Il ne rend pas la gestion des droits magique. Qui développe des analytics customer-facing teste l’isolation avec deux locataires et une tentative de jointure malveillante avant que le marketing n’active le feature-toggle.

Lisez honnêtement le modèle de coûts. Le serverless à la seconde semble bon marché et devient coûteux avec des full-scans incontrôlés. Mettez en place des gardes de requêtes, des limites par défaut et des métriques visibles en euros par tableau de bord. Sinon, vous remplacez les coûts de cluster inactif par des coûts de scan inactif.

Décision d’architecture sans dogme

DuckDB ne remplace pas chaque lakehouse. Il remplace le réflexe d’ouvrir un slot de data warehouse coûteux pour chaque évaluation. Iceberg et les catalogues restent la couche de vérité pour les grands ensembles de données partagées. DuckDB/MotherDuck se positionnent souvent devant ou à côté : rapides, embarqués, économiques en idle.

Pour les PME, le test honnête est un PoC d’une semaine. Prenez vos cinq requêtes ad-hoc les plus coûteuses et votre parcours d’analytics customer-facing. Mesurez les euros, la latence et l’effort d’exploitation par rapport au statu quo. Si la part d’idle domine votre calcul, la voie DuckDB n’est pas un effet de mode. C’est du FinOps avec SQL.

Foire aux questions

Source de l’image : générée par IA (juillet 2026)