Le rachat de DuckLabs par AWS n’est pas une simple opération cloud avec un logo de base de données. DuckLabs est l’entreprise d’Amsterdam autour de DuckDB, ce moteur analytique in-process que beaucoup d’équipes utilisent comme un “SQLite pour l’analytique”: notebooks, scripts Python et R, vérifications locales de Parquet, ETL léger, analytique embarquée et applications data sans entrepôt complet pour chaque question.

Moteur analytique ouvert se dirigeant vers un centre de données cloud avec bouclier communautaire

Le message officiel se veut rassurant. AWS acquiert DuckLabs, pas le projet open source DuckDB. DuckDB, DuckLake, Quack et les composants associés restent libres sous licence MIT. La DuckDB Foundation reste le steward indépendant. L’équipe demeure à Amsterdam, et Hannes Mühleisen ainsi que Mark Raasveldt continuent d’orienter la technique. Ces garanties comptent. Elles ne répondent pas à toute la question de gouvernance.

Ce qui change

DuckLabs a annoncé le 26 août 2026 son arrivée chez Amazon Web Services, avec une clôture attendue début septembre sous conditions habituelles. Amazon a confirmé un accord définitif. AWS présente l’opération comme un moyen de construire une analytique plus rapide et plus simple, notamment là où les données vivent déjà dans des formats ouverts et du stockage cloud.

Pour les utilisateurs, rien ne casse aujourd’hui. Le code DuckDB existant ne devient pas propriétaire. MIT reste permissif. Les scripts locaux continuent. La vraie question est plus lente: comment évoluent financement, feuille de route, intégrations et confiance quand le commercial steward passe chez AWS.

Pourquoi DuckDB compte

DuckDB a réussi parce qu’il a rendu le SQL analytique sérieux à nouveau local. Un data engineer inspecte un dataset Parquet avant un pipeline. Un analyste prototype une transformation dans un notebook. Une équipe ML prépare des features près des fichiers. Un produit embarque des requêtes analytiques sans exploiter un serveur séparé.

DuckDB se place donc entre local-first analytics et plateformes data cloud. Il est assez petit pour être embarqué et assez utile pour influencer l’architecture. Quand un hyperscaler achète l’entreprise autour de cette couche, les professionnels doivent regarder de près.

Ce qu’AWS peut chercher

AWS possède déjà une grande partie des lieux où vivent les données d’entreprise: S3, Glue, Athena, Redshift, EMR, notebooks et services AI/data. DuckDB est populaire autour des formats ouverts et des data lakes. Meilleures performances S3, chemins local-to-cloud plus fluides, services managés proches de DuckDB ou outillage lakehouse plus solide s’intègrent naturellement à la stratégie AWS.

La préversion DuckDB v2.0 rend le moment encore plus significatif. Elle mentionne Quack/CONNECT, des scénarios server et networked, un nouveau format de stockage, un nouveau parser, VARIANT, triggers et async I/O. Ce n’est pas une version de maintenance. C’est un projet qui se rapproche d’usages plus connectés et plus opérationnels.

Pourquoi la communauté s’inquiète

La discussion Hacker News a atteint environ 1024 points et 71 commentaires, entre félicitations et inquiétudes. La crainte n’est pas la disparition immédiate de MIT. Elle porte sur ce qui gouverne réellement un projet open source au quotidien.

Qui paie les mainteneurs? Qui relit les pull requests? Quelles intégrations obtiennent la meilleure documentation? Quel cloud devient le chemin le plus simple? Quelles APIs d’extensions se stabilisent? Quels utilisateurs pèsent quand il faut arbitrer? AWS n’a pas besoin de fermer le code pour déplacer le centre de gravité.

Pourquoi la Foundation compte encore

DuckDB Foundation est une protection réelle si elle détient la propriété intellectuelle et les marques, et si le code publié reste sous MIT irrévocable. Un fork demeure légalement possible. Les vendeurs indépendants peuvent continuer. Les entreprises peuvent embarquer DuckDB sans acheter un produit AWS.

Mais une fondation gagne la confiance par ses pratiques: conseil, décisions transparentes, feuille de route ouverte, politique d’extensions, processus de release et traitement équitable des contributeurs non AWS. La structure juridique réduit le risque; la gouvernance visible crée la confiance.

Que faire pour les entreprises

Il ne faut pas retirer DuckDB par réflexe. Il faut l’inventorier. Séparer notebooks et outils locaux des services de production, de l’analytique embarquée exposée aux clients et des ETL critiques. Vérifier versions, extensions et tests de régression. Garder des données en formats portables.

Si des intégrations AWS apparaissent, demander si elles restent optionnelles et portables. Une fonction managée AWS peut être un bon choix pour une équipe AWS-first. Elle ne doit pas devenir par accident la dépendance cachée d’une plateforme censée rester neutre.

Lecture pratique

Le scénario positif est crédible: AWS apporte ressources, distribution et profondeur d’ingénierie tandis que DuckDB reste suffisamment ouvert et neutre. Le scénario négatif l’est aussi: le code reste ouvert, mais l’énergie de la feuille de route penche vers AWS et les vendeurs indépendants se sentent moins égaux.

Les deux sont possibles parce que l’open source est à la fois une licence, une communauté et une économie. Cette acquisition modifie l’économie même si le dépôt reste ouvert.

La bonne réponse est une confiance vigilante. Continuer à utiliser DuckDB là où il convient, suivre la DuckDB Foundation autant que les annonces AWS, et juger surtout les prochaines releases et décisions de gouvernance. Le code reste ouvert. Le centre de gravité a bougé.