DuckDB es una base de datos SQL analítica en proceso que se ha convertido, desde su origen como proyecto de investigación del CWI de Ámsterdam en 2019, en uno de los motores analíticos mononodo más usados y más rápidos del momento. Se distribuye como un binario único de menos de 20 MB, se instala con pip o brew, y abre directorios de Parquet, CSV o JSON como si ya fueran tablas SQL, sin servidor, sin migraciones y sin creación de esquema previa. Empresas como MotherDuck, Hex, Omni, Evidence, Fivetran y Rill, además del propio Greybeam, lo han incorporado como motor de ejecución o caché en sus plataformas.
Su velocidad se explica por un conjunto de decisiones de diseño. La primera es la ausencia de un protocolo cliente-servidor: al vivir como librería dentro del mismo proceso que la aplicación, DuckDB evita la serialización fila a fila propia de ODBC y JDBC, que según el trabajo de Mark Raasveldt y Hannes Mühleisen "Don't Hold My Data Hostage" (2017) puede ser la fase más lenta de toda la consulta. Para integrarse con Pandas o NumPy emplea replacement scans y, cuando los buffers son compatibles, lecturas zero-copy, y con Arrow comparte directamente memoria columnar tipada, lo que elimina buena parte de las conversiones.
La segunda palanca es su pipeline de compilación. DuckDB parsea el SQL con un fork del parser de Postgres para generar un AST, lo pasa por una fase de bind que resuelve nombres, tipos y referencias del catálogo, y llega al optimizador y al planificador físico, que reescriben y transforman la consulta antes de la ejecución. El artículo explica en detalle cada una de estas etapas y la capa de almacenamiento que las alimenta; la fase de ejecución se aborda en una segunda parte.