DuckDB v2.0 reemplaza su parser SQL con PEG

¿Por qué DuckDB reemplazó su parser SQL?

DuckDB v2.0 reemplaza por completo su parser SQL heredado de PostgreSQL con uno basado en Gramáticas de Expresiones de Análisis (PEG), una decisión arquitectónica que busca facilitar la evolución del lenguaje y habilitar extensiones en tiempo de ejecución. Con más de 6 millones de descargas mensuales y adopción en empresas como Facebook, Google y Airbnb, este movimiento marca un punto de inflexión para una de las bases de datos analíticas embebidas más populares del ecosistema.

El cambio no afecta la sintaxis que los usuarios conocen —queries existentes seguirán funcionando— pero transforma lo que hay debajo del capó. El nuevo parser procesa cada consulta SQL a través de tres etapas: el tokenizer divide el texto en tokens (palabras clave, números, identificadores), el parser PEG valida que sigan la gramática de DuckDB y produce un árbol de resultados genérico, y el transformer convierte ese resultado en el árbol de sintaxis abstracta (AST) interno que usa el resto del pipeline de consulta.

¿Qué problema resuelve el parser PEG?

La arquitectura anterior usaba un parser derivado de YACC/Bison, que genera un parser LALR(1). Esta tecnología madura funcionó bien durante años, pero presentaba limitaciones crecientes: agregar nuevas reglas al grammar podía generar conflictos de shift/reduce o reduce/reduce, haciendo que evolucionar el dialecto SQL de DuckDB se volviera progresivamente más difícil.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Los parsers PEG eliminan estos conflictos porque evalúan las alternativas en orden explícito. Cuando una regla tiene múltiples opciones, intenta cada una secuencialmente y selecciona la primera que coincide. Ese orden forma parte del comportamiento del grammar, no un efecto secundario de la ambigüedad.

Un precedente relevante en la industria: Python también migró de su parser LL(1) a uno PEG en Python 3.9, motivado por la misma necesidad de flexibilidad para evolucionar el lenguaje. La tendencia sugiere que los parsers PEG están ganando terreno en proyectos donde la extensibilidad es prioritaria.

¿Cómo mejoró el rendimiento con packrat parsing?

Uno de los desafíos técnicos más significativos fue evitar el backtracking exponencial. Un parser PEG ingenuo puede evaluar la misma regla gramatical múltiples veces en la misma posición del token mientras prueba diferentes alternativas. En inputs malformados con muchos paréntesis sin cerrar, esto generaba tiempos de parseo que se duplicaban con cada paréntesis adicional:

18 paréntesis abiertos: 5.3 segundos
19 paréntesis abiertos: 10.6 segundos

La solución implementada fue packrat parsing, una técnica de memoización que almacena el resultado de aplicar cada matcher en una posición específica del token. Si el parser intenta el mismo matcher en la misma posición nuevamente, reutiliza el resultado cached. Con esta optimización, la misma consulta con 19 paréntesis se rechaza en 0.001 segundos.

Este trade-off consume memoria adicional durante el parseo, pero evita casos patológicos donde queries malformadas podrían bloquear el sistema indefinidamente.

Nuevas capacidades habilitadas por el parser PEG

Con el nuevo parser, DuckDB ha introducido varias extensiones sintácticas que hubieran sido considerablemente más complejas con el enfoque anterior:

Sentencias de expresión sin SELECT. Ahora es posible ejecutar expresiones directamente sin envolverlas en un SELECT:

date: current_date(), time: current_localtime();

Conexión remota con CONNECT. El nuevo statement permite conectar a bases de datos remotas y enrutar consultas subsiguientes:

CONNECT 'postgres://localhost/mydb';
SELECT count(*) FROM orders;
DISCONNECT;

Recursos externos. Nueva sintaxis para gestionar recursos fuera de DuckDB directamente desde SQL:

CREATE EXTERNAL RESOURCE '<resource-type>' AS <name> (...);
SHOW EXTERNAL RESOURCES;
DESTROY EXTERNAL RESOURCE <name>;

COPY TO con particionamiento. Se añadió soporte para PARTITION BY y ORDER BY en operaciones de exportación:

COPY orders TO 'orders'
(
    FORMAT parquet,
    PARTITION BY (year, month),
    ORDER BY (order_date)
);

Extensiones en tiempo de ejecución: el verdadero salto

Lo más significativo del parser PEG no son las nuevas sintaxis, sino la capacidad de que extensiones agreguen reglas gramaticales directamente al parser de DuckDB mientras reutilizan las reglas existentes. Esto elimina la necesidad de parsers fallback que intentan parsear primero DuckDB y luego delegan en la extensión si falla.

Como ejemplo conceptual, la sintaxis de pipes (inspirada en Google) permitiría expresar flujos de datos como secuencias de operadores:

FROM produce
  |> WHERE item != 'bananas'
  |> AGGREGATE COUNT(*) AS num_items
  |> ORDER BY item DESC;

La extensión solo define las reglas específicas de pipe (PipeSelectAtom, PipeStage, PipeOperator) y reutiliza reglas existentes como GroupByClause y sus transformadores correspondientes. Esto significa que una extensión no necesita reimplementar GROUP BY, SELECT u otras cláusulas estándar.

La API de extensión mostrada en el artículo sigue siendo preliminar y puede cambiar antes del lanzamiento oficial de v2.0. Los desarrolladores pueden seguir el progreso en GitHub.

Contexto del ecosistema: DuckDB sin venture capital

Un dato relevante sobre la estructura de DuckDB: DuckLabs (anteriormente DuckDB Labs) decidió no recibir financiamiento de venture capital, optando por mantener el proyecto abierto bajo licencia MIT. Según sus creadores, «sentimos que la inversión obligaría a dirigir el proyecto hacia la monetización, y preferiríamos mantener DuckDB abierto y disponible para la mayor cantidad de personas posible».

El proyecto es custodiado por la DuckDB Foundation, una organización sin fines de lucro fundada por los coautores Mark Raasveldt y Hannes Mühleisen en el Centrum Wiskunde & Informatica (CWI) de los Países Bajos. La fundación recibió la propiedad intelectual del proyecto y está financiada por donaciones caritativas, asegurando que DuckDB permanezca open-source en perpetuidad.

Existe una empresa independiente llamada MotherDuck que construye una plataforma de datos basada en DuckDB y ha recibido más de $100 millones en financiamiento con inversores como Andreessen Horowitz. Esta separación entre el proyecto open-source y las aplicaciones comerciales basadas en él modela un enfoque interesante para startups de infraestructura de datos.

¿Qué significa esto para tu startup?

Si tu equipo trabaja con análisis de datos, pipelines ETL o herramientas de business intelligence, el parser PEG de DuckDB v2.0 tiene implicaciones concretas:

1. Evaluá migrar procesos analíticos a DuckDB si aún no lo hiciste. Con 6 millones de descargas mensuales y adopción en grandes tecnológicas, DuckDB se posicionó como la base de datos analítica embebida de referencia. El nuevo parser facilita que la comunidad cree extensiones especializadas que podrían resolver problemas específicos de tu stack sin depender de desarrollo interno.

2. Prepará tu estrategia de extensiones si construís herramientas sobre DuckDB. La capacidad de extender el parser en tiempo de ejecución abre posibilidades que antes eran prohibitivas. Si necesitás syntax personalizada para dominios específicos (lenguajes de consulta internos, integraciones con sistemas legacy), ya no necesitás reimplementar todo el parser SQL.

3. Monitoreá la API de extensiones antes de invertir en desarrollo. La interfaz mostrada en el artículo es preliminar y puede cambiar. Esperá al lanzamiento estable de v2.0 antes de comprometer código de producción a la API de grammar extension.

4. Considerá el modelo DuckLabs/MotherDuck si estás evaluando financiamiento para infraestructura open-source. La decisión de DuckLabs de operar sin VC contrasta con el modelo de MotherDuck, que sí captó capital institucional. Ambos enfoques coexisten, y vale analizar cuál se alinea mejor con los incentivos de tu equipo y tus objetivos a largo plazo.