Contexte technique

DuckDB 2.0, version alpha publiée à l’automne 2026, cible les charges de travail analytiques où les données résident sur des stockages d’objets comme Amazon S3. L’auteur a mesuré les performances sur un ordinateur portable M5 en utilisant une connexion internet domestique vers la région us-east-1. Le benchmark porte sur un fichier Parquet de 2,2 Go contenant 228 millions de lignes, découpé en 2 268 groupes de lignes (environ 122 000 lignes chacun). La requête ne lit qu’une colonne (≈ 230 Mo) et agrège le nombre de votes par type.

CREATE SECRET s3 (TYPE s3, PROVIDER credential_chain, REGION 'us-east-1');
SET enable_external_file_cache = false; -- force chaque exécution à toucher S3
SELECT VoteTypeId, count(*) AS n
FROM read_parquet('s3://us-prd-motherduck-open-datasets/stackoverflow/parquet/2023-05/votes.parquet')
GROUP BY ALL
ORDER BY 1;

Mécanisme d’async I/O

Dans la version 1.5.5, chaque worker (au nombre de 18) exécute séquentiellement les étapes suivantes : téléchargement du groupe de lignes, attente réseau, décodage du Parquet, puis passe au groupe suivant. Cette alternance crée des périodes d’inactivité CPU pendant les attentes réseau et empêche le parallélisme des téléchargements : au maximum 18 flux sont actifs simultanément.

DuckDB 2.0 introduit un pool dédié aux téléchargements. Ce pool maintient « des dizaines » de groupes de lignes en vol, les stocke dans un tampon partagé, puis les met à disposition des workers qui ne font que décoder. Ainsi, le réseau et le CPU sont exploités en même temps : pendant que le CPU traite un groupe, le pool télécharge le suivant. Le schéma passe d’une chaîne « download → wait → decode » à une architecture « download en arrière‑plan + decode en avant‑plan », éliminant les temps morts.

Impact mesuré sur les performances

Le même script exécuté avec DuckDB 1.5.5 a nécessité 18,8 s. Avec l’alpha 2.0, le temps est passé à 7,7 s, soit une réduction de 58 % sur ce scénario. Le gain provient exclusivement du parallélisme réseau ; le nombre d’opérations CPU (décompression, agrégation) reste identique. Le benchmark souligne que la latence domestique ralentit les deux versions de façon similaire, donc le facteur d’accélération devrait être encore plus prononcé sur des instances cloud où la bande passante vers S3 est supérieure.

Limites et bonnes pratiques

Le bénéfice d’async I/O dépend de la granularité des fichiers. Un découpage en nombreux petits groupes (ici 2 268) favorise le remplissage du tampon et la mise à profit du pool de téléchargement. Des fichiers monolithiques ou très peu fragmentés limiteraient le nombre de flux parallèles, réduisant l’avantage. De plus, la désactivation du cache externe (enable_external_file_cache = false) garantit que chaque exécution touche réellement S3 ; en production, activer le cache pourrait masquer une partie du gain observable. Enfin, la version testée est une alpha ; les optimisations de planification et la stabilité du pool de threads restent sujettes à évolution avant la version stable.