Arrêtez de déployer un data warehouse : intégrez DuckDB 2.0 pour l’analytique en temps réel

Vous payez des prix d’entrepôt pour afficher 12 vignettes sur un tableau de bord client. Chaque clic fait appel à un service cloud qui facture à la requête, à la seconde et à l’octet scanné. La latence est imprévisible. La facture ne l’est pas. Avec DuckDB 2.0 à l’horizon (la preview circule déjà), il est temps d’inverser le défaut : mettez l’OLAP dans votre application, pas dans un entrepôt lointain.

Le moteur colonnaire embarqué de DuckDB est le secret le moins bien gardé de la data depuis des années. Ce qui change aujourd’hui, c’est la maturité. Le cycle 2.0 signale une base stable, des E/S plus rapides et une histoire plus claire pour les extensions et la gestion de résultats volumineux. Pas besoin d’attendre le label GA pour démarrer un pilote : l’architecture et les compromis sont bien compris. Et pour une large classe de tableaux de bord SaaS, d’analytique in‑product et d’exploration ad hoc, l’OLAP embarqué bat les services de requêtage serverless sur le coût, la latence, la confidentialité et la simplicité.

Ce qui se passe mal quand vous « shippez » un entrepôt

Les entrepôts et moteurs de requêtes serverless excellent pour l’analytique multi‑tenant et cross‑domaine. Ils sont mauvais pour alimenter des interactions produit en temps réel. Vous le sentez à trois niveaux :

• Unit economics sans bornes. Si vous poussez 100 k chargements de tableaux de bord/jour à 5 $ pour 1 000 requêtes, cela fait ~15 k$/mois de frais de requêtes avant le stockage, l’egress ou les « accélérateurs ». Ça grimpe avec la croissance, car le cache optimisé est le problème de quelqu’un d’autre.
• Latence UI que vous ne maîtrisez pas. Même rapides, les entrepôts fluctuent. Un « simple » group‑by sur quelques Go peut prendre 200 ms le lundi, 1,5 s le vendredi, et le coût pour réduire cet écart retombe sur vous.
• La gravité des données vous freine. Exporter des tables de caractéristiques, des logs d’événements ou des snapshots par client vers un entrepôt ajoute des pipelines, des backfills et des modes de panne. Audits et résidence des données multiplient la surcharge.

Quand la question est « afficher à ce client ses 90 derniers jours d’usage avec 5 filtres », vous n’avez pas besoin d’un réseau de feuilles à l’échelle d’Internet. Vous avez besoin de scans colonnaires rapides, in‑process, avec un contrôle serré du CPU, du cache et de la mémoire.

Où DuckDB 2.0 change le défaut

DuckDB est un moteur SQL colonnaire vectorisé que vous pouvez embarquer dans votre app (C/C++, Python, Node, Rust, Go, Java) et pointer sur des Parquet, CSV ou buffers Arrow. C’est de l’OLAP sans cluster : les requêtes analytiques s’exécutent dans votre processus, sur la même machine que votre app ou vos workers.

Ce que la voie 2.0 signifie pour les CTOs n’est pas une fonctionnalité magique unique — c’est un jalon de stabilité et de performance. Attendez‑vous à des chemins d’E/S plus rapides, plus de marge sur de grands résultats, et de meilleures ergonomies pour les extensions et la gestion de fichiers. Si vous attendiez une ligne de version majeure pour standardiser, c’est votre signal.

Des bénéfices concrets et bancables

• Latence prévisible : L’exécution vectorisée colonnaire sur stockage local maintient des 95e percentiles serrés. Pour des jeux de données par client de 1–5 Go, des agrégats sous la seconde sur des instances commoditisées 8–16 cœurs sont la norme si vous concevez pour la localité de cache.
• Zéro taxe par requête : Les requêtes ne vous facturent pas. Les instances, si. Un serveur de classe c6i.2xlarge (8 vCPU, 16–32 Go de RAM) peut gérer des milliers de rendus de tableaux de bord quotidiens avec de la marge.
• Confidentialité et résidence par défaut : Conservez l’analytique dans la région du client, voire sur l’appareil. Pas de synchronisation transfrontalière vers un data plane tiers juste pour calculer des utilisateurs actifs quotidiens.
• Ergonomie développeur saine : Livrez du SQL, pas une flotte. Pas de drivers à babysitter, pas de connexions externes à tuner, pas de retries opaques. Votre app possède le cycle de vie.

Cadre de décision : quand embarquer vs. entrepôt

Ne supprimez pas votre entrepôt. Tracez une ligne. Si la plupart de votre analytique produit correspond à la colonne de gauche, commencez à embarquer DuckDB. Si vous êtes à droite, gardez l’entrepôt et optimisez.

Adéquation cas d’usage

• Excellent pour DuckDB : Tableaux de bord par client, analyses de cohortes sur 10–100 M de lignes, agrégats fenêtrés dans le temps, filtrage interactif avec 3–8 dimensions, exploration de feature store, ingestion et QA de CSV/Parquet, analytique hors‑ligne sur desktop/mobile.
• Gardez l’entrepôt : Jointures cross‑clients sur des To de données, centaines d’utilisateurs concurrents interrogeant le même dataset, motifs d’accès avec longues jointures, politiques de gouvernance centralisées dans l’entrepôt, équipes BI construisant des modèles fédérés.

Ordres de grandeur de dimensionnement

• Données par client sous ~10 Go (compressées) : Candidat solide pour l’embarqué. Plus grand reste jouable avec partitionnement et streaming, mais testez la marge mémoire.
• Requêtes concurrentes par instance < ~20 : DuckDB scale verticalement ; vous multiplexez avec les threads de l’app ou exécutez des workers par client. Si vous avez besoin de 200+ requêtes lourdes concurrentes sur les mêmes données, un entrepôt sera plus simple opérationnellement.
• Fraîcheur = minutes à heure : L’embarqué brille quand vous pouvez mettre à jour des snapshots selon un horaire ou ajouter en append à des Parquet partitionnés. Si vous avez des mises à jour seconde par seconde à travers les clients, gardez la voie entrepôt pour ces flux.

Garde‑fous

• Pas de SQL arbitraire fourni par l’utilisateur : Ne laissez pas l’app ou un LLM improviser du SQL. Compilez un petit DSL en SQL paramétré. Un récent billet de dev l’a dit crûment : ne donnez pas du SQL au modèle. Vous livrerez plus sûr et plus vite.
• Isolation des fichiers : Un fichier par client ou par espace de travail. Pas de partage cross‑clients sur disque. Cela rend snapshots, sauvegarde et suppression gérables.
• Hygiène des extensions : Ne listez que des extensions auditées. Embarqué signifie que votre processus constitue le périmètre d’impact.

Architectures de référence que vous pouvez livrer ce trimestre

1) OLAP embarqué côté serveur, par client

Pattern : Pour chaque client, maintenez un lac Parquet partitionné dans du stockage objet. À la requête, votre app ouvre une connexion DuckDB, attache le répertoire Parquet, exécute du SQL paramétré et renvoie du JSON à l’UI. Mettez en cache les agrégats chauds dans Redis avec un TTL.

• Avantages : Infra minimale, coût prévisible, audit facile. Les snapshots ne sont que du versioning de stockage objet. Idéal pour 1–10 k clients avec un trafic léger à modéré.
• Inconvénients : Vous gérerez la contention CPU sur des nœuds partagés. Les cold starts paient une taxe d’E/S à moins d’épingler les partitions chaudes sur du NVMe local.

2) Matérialisation pilotée par workers

Pattern : Les flux d’événements aboutissent en fichiers colonnaires (Parquet). Un worker périodique (15–60 minutes) compacte et rafraîchit des tables dérivées (rollups, tuiles) avec DuckDB. L’app sert des résultats pré‑agrégés avec pushdown de filtres.

• Avantages : P95 < 200 ms pour des tableaux de bord répétitifs. Très bon marché à scaler. Facile d’appliquer des SLA.
• Inconvénients : Moins interactif pour des explorations arbitraires au‑delà des formes pré‑calculées.

3) Analytique on‑device avec WebAssembly

Pattern : Pour des produits client‑heavy, préchargez duckdb‑wasm et expédiez des tranches de données chiffrées vers le navigateur ou le desktop. Exécutez les requêtes localement ; ne renvoyez que des agrégats pour audit ou synchronisation.

• Avantages : Zéro coût serveur par requête, interactivité instantanée, posture de confidentialité forte. Idéal pour des clients entreprise qui ne laissent pas leurs données sortir de la VPC sans bataille.
• Inconvénients : Taille du package, plafonds mémoire et complexité des mises à jour. Vous avez besoin d’une stratégie robuste de contenu pour les paquets de données.

4) Hybride avec un service DuckDB hébergé

Pattern : Utilisez un service compatible DuckDB hébergé pour la collaboration, la sémantique multi‑writer ou le partage SQL (p. ex. des analystes qui itèrent sur des métriques) tandis que le chemin de votre app reste embarqué pour les requêtes runtime.

• Avantages : Le meilleur des deux mondes pour des équipes dont les analystes exigent l’ergonomie SQL sans imposer un entrepôt au chemin produit.
• Inconvénients : Vous gérerez deux voies — gardez le chemin critique produit embarqué pour protéger latence et coût.

Performance et planification de capacité sans mauvaises surprises

Façonnez vos données pour les caches CPU

• Colonnaire de bout en bout : Stockez en Parquet par défaut. Choisissez des types de colonnes judicieux. Encodez les variables catégorielles ; évitez le texte libre dans les chemins chauds.
• Partitionnez là où ça compte : Le temps (par mois/semaine) et les IDs client/espace de travail. Cela réduit drastiquement le volume scanné.
• Tuilez vos visuels lourds : Pré‑calculez des tuiles de carte de chaleur 256×256, des buckets d’histogrammes ou des tables de percentiles. Puis filtrez et assemblez à la demande.

Connaissez votre enveloppe mémoire

• Visez 1–2× la taille des données compressées comme ensemble de travail sûr pour des group‑by complexes. Si les données compressées d’un client font 6 Go, prévoyez 8–12 Go de marge RAM lors de l’exécution de leurs requêtes interactives les plus lourdes.
• Épinglez les partitions chaudes sur du NVMe si vous comptez sur des scans à froid fréquents ; DuckDB adore une bande passante de lecture locale rapide. Utilisez le stockage objet pour la longue traîne.
• Throttle de la concurrence avec un simple token bucket par nœud. Ne laissez pas 30 requêtes simultanées à 8 cœurs se battre sur une machine 16 cœurs.

Sécurité et gouvernance dans un monde embarqué

• La sécurité niveau ligne est dans votre couche applicative : Avec un fichier par client, votre logique d’autorisation reste simple : soit vous pouvez monter ce dataset, soit non. Évitez les fichiers cross‑clients qui forcent des politiques RLS complexes.
• Surface SQL : Construisez une API sûre qui compile l’intention utilisateur en modèles SQL. Pas d’accès arbitraire au système de fichiers, ni de création d’UDF (fonctions définies par l’utilisateur), ni d’échappements shell. Auditez chaque requête exécutée avec ses paramètres.
• Chiffrement et suppression : Chiffrez au repos via les clés du stockage objet, plus des clés applicatives si vous livrez côté client. Intégrez la suppression au cycle de vie des partitions ; prouvez l’effacement via des tombstones de versions d’objets et la révocation de clés.
• Les sauvegardes sont des copies de fichiers : Snapshot des répertoires Parquet. Vérifiez la restauration en démarrant chaque heure une instance de staging avec le dernier snapshot et en exécutant une smoke suite.

Des coûts qui s’améliorent réellement avec l’échelle

Voici une comparaison budgétaire conservatrice pour un SaaS à un stade intermédiaire servant 50 k vues de tableaux de bord/jour :

• Voie entrepôt : 50 k requêtes × 5 $/1 000 = 250 $/jour de frais de requêtes (~7,5 k$/mois), plus stockage, réservations de compute et egress. Réalistement 10–20 k$/mois pour la seule tranche analytique produit.
• Voie embarquée : 3× instances type c7i.2xlarge (~350 $/mo chacune) + stockage/NVMe + ingénierie nearshore pour livrer et maintenir. Infra : ~1,5–3 k$/mois. Ingénierie amortie : dépend de votre équipe, mais la plupart voient un payback en 2–4 mois vs. les factures d’entrepôt.

Rien de tout cela ne comptabilise le delta de latence visible utilisateur (sous la seconde versus plusieurs secondes). Des tableaux de bord plus rapides convertissent mieux les essais, réduisent les abandons et coupent les tickets support — des bénéfices mal capturés par la finance mais visibles dans vos métriques de croissance.

30/60/90 : un plan de déploiement pragmatique

Jours 0–30 : inventaire et pilote

• Journalisez chaque forme de requête de votre app aujourd’hui : dimensions, filtres, fenêtres de temps et tailles de résultats. Vous constaterez que 80 % entrent dans une douzaine de patterns.
• Montez un dépôt pilote embarquant DuckDB dans le langage principal de votre app. Connectez‑vous à un snapshot Parquet par client. Recréez trois tableaux de bord les plus lourds avec du SQL paramétré.
• Tests de référence (« golden tests ») : validez l’égalité avec les résultats de votre entrepôt sur des snapshots figés. Rendez cela répétable en CI.

Jours 31–60 : durcissement opérationnel

• Partitionnement et compactage : construisez le job de compactage pour créer du Parquet partitionné par client, chaque nuit ou chaque heure selon le besoin de fraîcheur.
• Stratégie de cache : ajoutez un cache de 5–15 minutes par agrégat coûteux. Affichez « données au HH:MM » dans l’UI.
• Contrôles de concurrence : introduisez un token bucket par nœud. Basculez rapidement vers le cache, ou dégradez vers des tuiles pré‑calculées sous charge.
• Posture de sécurité : verrouillez les extensions. Retirez les primitives système de fichiers de la surface SQL. Conservez chaque requête exécutée pour audit.

Jours 61–90 : basculer le chemin par défaut en toute sécurité

• Lancement discret (dark launch) : routez 10–20 % des clients vers l’embarqué, mesurez la latence P50/P95 et la justesse. Montez à 50–70 % si le budget d’erreur tient.
• Contrôles de coûts : coupez le compute de l’entrepôt pour cette tranche. Gardez une voie de secours (« break glass ») pendant deux semaines le temps de monitorer.
• Montée en compétence de l’équipe : publiez vos modèles SQL et la doc du DSL. Formez PM/analystes sur ce qui est possible in‑UI versus ce qui reste dans l’entrepôt.

Arbitrages à accepter

• Scalabilité verticale, pas horizontale : DuckDB aime les gros cœurs et les disques locaux rapides. Si votre modèle mental est « ajouter un nœud = aller plus vite », vous serez déçus. À la place, segmentez par client ou par espace de travail.
• Réalités single‑writer : La concurrence va bien pour les lectures ; les jobs de compactage et de matérialisation doivent être planifiés pour éviter les conflits frontaux. Si vous avez réellement besoin de multi‑writer à forte concurrence, un service hébergé compatible DuckDB ou votre entrepôt peut faire sens pour les chemins d’édition.
• Tolérance limitée aux requêtes longues : L’embarqué n’est pas le bon endroit pour des jointures de 5–30 minutes. Bornez la durée des requêtes et concevez l’UX pour encourager des chemins pré‑calculés pour les gros travaux.
• La justesse vous incombe : Il n’y a pas de « service mystérieux » à blâmer. La bonne nouvelle : vos snapshots de test, requêtes de référence (« golden queries ») et votre CI peuvent prouver la justesse à chaque release.

Pourquoi c’est un mouvement nearshore‑friendly

L’analytique embarquée paie le plus vite quand vous pouvez itérer dans la base de code de l’app avec des boucles de feedback courtes. C’est un sweet spot nearshore : 6–8 heures de recouvrement avec les fuseaux US, faible surcharge d’intégration et livrables clairs (tableaux de bord X/Y/Z passés à l’embarqué ; P95 sous 800 ms ; N $ économisés/mois). Nous voyons régulièrement un petit pod — 1 senior backend, 1 data engineer, 1 full‑stack — livrer un pilote en 3–4 semaines et basculer 60 % de l’analytique produit en un trimestre.

L’essentiel

Les entrepôts ne vont pas disparaître. Mais si vous les utilisez pour rendre des tableaux de bord par client, vous achetez une voiture de Formule 1 pour rouler dans un centre commercial. Avec la maturité de DuckDB 2.0, l’OLAP embarqué devient le défaut sain pour l’analytique orientée produit : moins cher, plus rapide et plus simple à opérer. Tracez votre ligne et migrez ce qui relève de la gauche — maintenant.

Points clés

• Ne shippez pas un entrepôt pour des tableaux de bord par client ; embarquez DuckDB et gardez l’analytique dans votre app.
• Ciblez des jeux de données par client sous ~10 Go (compressés) et moins de 20 requêtes lourdes concurrentes par nœud.
• Stockez les données en Parquet partitionné, compilez l’intention utilisateur en SQL paramétré et limitez la concurrence.
• Attendez‑vous à un P95 sous la seconde pour des agrégats courants sur des instances 8–16 cœurs et à une réduction de coût de 3–10× versus les services facturés à la requête.
• Déployez en 90 jours : pilotez 3 tableaux de bord, durcissez compactage/cache, lancez discrètement 20–70 % des clients, puis réduisez la dépense entrepôt pour cette tranche.