DuckDB prepara su mayor salto arquitectónico en años: a partir de la versión 2.0, prevista para otoño de 2026, el motor de bases de datos analíticas incorporará E/S asíncrona de forma predeterminada para la lectura de archivos Parquet y CSV, una mejora que promete acelerar de forma significativa las consultas sobre datos almacenados en la nube, como los data lakes en S3 o setups similares sobre EC2.
Hasta ahora, la estrategia de DuckDB frente al coste de mover datos había sido evitarlo: filtros y proyecciones pushdown permitían podar agresivamente antes de tocar disco, algo especialmente eficaz en SSD locales, donde la latencia es baja y el ancho de banda alto. Sin embargo, según explica el equipo en el blog oficial de DuckDB, esa premisa dejó de cumplirse a medida que el motor se adoptó para escenarios de datos a gran escala en almacenamiento remoto, culminando con la posibilidad, disponible desde mayo de este año, de ejecutar DuckDB como servidor mediante el protocolo Quack.
En configuraciones típicas de data lake, los archivos residen en blob storage como S3 y se procesan en instancias EC2 de la misma región. En ese contexto, la latencia y el ancho de banda de red se vuelven críticos: si no se emiten suficientes peticiones concurrentes, los hilos pasan la mayor parte del tiempo bloqueados esperando lecturas remotas en lugar de decodificar, agregar o unir datos. Con E/S síncrona, el hilo worker permanece inactivo hasta que los bytes solicitados llegan a la máquina, desaprovechando los recursos de CPU.
La solución implementada por DuckDB se basa en un pipeline asíncrono con dos pools de hilos diferenciados. El pool REGULAR agrupa a los worker threads —uno por núcleo de CPU disponible por defecto— encargados del trabajo real: decodificación, joins y agregaciones. El pool ASYNC, en cambio, concentra hilos dedicados principalmente a operaciones de E/S bloqueantes. Su número predeterminado es cuatro veces la cantidad de hilos del sistema, con un tope de 256, precisamente porque estos hilos pueden pasar casi todo su tiempo esperando respuestas HTTP y presentan una utilización de CPU muy baja.
Para mantener ocupados a los hilos ASYNC, DuckDB adopta una estrategia de read-ahead: en lugar de emitir lecturas justo cuando el worker las necesita, programa tareas de fetch por adelantado, de modo que mientras un worker decodifica un job, los hilos asíncronos ya están incorporando los datos de los siguientes. En Parquet, un job equivale a un row group, que puede descomponerse en varias tareas de fetch según las proyecciones, filtros pushdown y la ubicación física de las columnas. En CSV UTF-8 descomprimido y seekable, un job corresponde a un límite de escaneo sobre un rango fijo de bytes; las tareas de fetch cargan el buffer inicial del job y, cuando el escaneo llega al final del buffer, también el siguiente, para manejar líneas divididas entre buffers.
Cualquier worker regular que busca trabajo de escaneo se encarga de rellenar la cola hasta donde el presupuesto de memoria o el número de slots lo permita. Las tareas de fetch se programan de inmediato en el pool ASYNC, mientras que los jobs se admiten en la cola de read-ahead en orden de lote. Los hilos ASYNC ejecutan las tareas de fetch de manera independiente; tareas de un mismo job pueden correr de forma concurrente y comparten un contador que, al llegar a cero, completa la E/S del job.
El equipo reconoce un riesgo inherente al read-ahead: el consumo de memoria. Si la decodificación es lenta pero la red es rápida, los datos prefetched pueden acumularse y provocar errores por falta de memoria. Para mitigarlo, DuckDB ha implementado además un sistema de gobernanza asíncrona de memoria que limita la cantidad de datos que se adelantan.
En su estado actual, la E/S asíncrona está implementada para Parquet y para CSV UTF-8 sin comprimir y seekable. El soporte para otros formatos, como el formato nativo de DuckDB y JSON, está previsto pero aún no llega. Los usuarios que quieran probarla ya pueden hacerlo mediante las versiones preview de DuckDB v2.0.0-dev, aunque el encendido por defecto no ocurrirá hasta el lanzamiento oficial de v2.0 en otoño de 2026.
La apuesta es clara: tras años optimizando el camino de acceso a datos asumiendo SSD local, DuckDB reconoce que su futuro —data lakes, despliegues en la nube y ejecución como servidor— exige repensar ese pilar. Si los benchmarks publicados acompañan a la funcionalidad, la v2.0 podría consolidar a DuckDB como una opción de referencia para analizar datasets remotos sin sacrificar la simplicidad que lo ha caracterizado.