CoffeeQL, un motor de consultas unificado para SQL, NoSQL y Redis en Rust
La nueva versión 0.3.1 ofrece bindings para JavaScript y Python, pero las operaciones de escritura reales llegan en la 0.4.0.
Khushvi Bamrolia ha liberado CoffeeQL en su versión 0.3.1. Es un lenguaje de consulta escrito en Rust con el objetivo de abstraer la sintaxis específica de PostgreSQL, MongoDB, MySQL y Redis bajo un mismo formato. El proyecto se publica en npm y PyPI, ofreciendo bindings nativos para JavaScript y Python, aunque el motor central corre sobre el mismo código base compilado.
La propuesta ataca el cambio de contexto que sufren los equipos que mantienen estacks politecnológicos. Es habitual gestionar datos relacionales en PostgreSQL, documentos en MongoDB, caché en Redis y servicios legacy en MySQL. Cada capa exige una sintaxis distinta, drivers diferentes y modelos mentales separados para operaciones idénticas. CoffeeQL intenta normalizar esto mediante un DSL (lenguaje específico de dominio) propio.
La sintaxis opta por una estructura encadenada y funcional. Una operación de lectura se define así:
users []. where ( id = 1 ). give ( name , email )
Este mismo bloque se reenvía al driver correspondiente según la conexión activa. La versión actual soporta planificación de consultas y el método explain(), lo que permite inspeccionar cómo el motor traduce la abstracción a la consulta nativa subyacente. La limitación de resultados se maneja con .cup(10), y los filtros por fecha o valor mantienen la misma estructura.
La elección de Rust responde a dos necesidades: la seguridad de tipos en tiempo de compilación para manejar la complejidad de traducir un AST a cuatro modelos de ejecución diferentes, y la portabilidad. Gracias a WebAssembly y PyO3/maturin, un único código fuente genera artefactos listos para entornos Node.js y Python sin mantener bases de código duplicadas ni riesgos de divergencia lógica.
Estado real de la implementación
Hay que leer las notas de la versión con atención. La 0.3.1, disponible hoy, es principalmente un planificador de consultas. El código es capaz de analizar la sintaxis unificada y generar el plan de ejecución, pero no realiza las operaciones de escritura ni la gestión completa de transacciones. La capacidad de ejecutar CRUD real está programada para la versión 0.4.0.
En esa próxima iteración se incorporarán los drivers asíncronos para Python (asyncpg, motor, aiomysql, redis-py) y se reconstruirá el paquete de npm con manejo de errores completo. También habrá un paquete para Dart y una cláusula .raw() para casos en que la abstracción no cubra una necesidad específica o exija passthrough directo al motor de base de datos. Hasta entonces, CoffeeQL funciona como una capa de validación y traducción sintáctica, no como un executor de datos pleno.
El proyecto tiene 265 pruebas automáticas pasando, lo que sugiere una cobertura razonable de los casos de uso previstos para la traducción de consultas. Para un equipo que busca estandarizar la lectura de datos en un entorno poliglota, la herramienta podría reducir la fricción cognitiva. Para quien necesita garantías de consistencia en escrituras distribuidas o transacciones complejas, la versión actual no ofrece aún el motor de ejecución necesario. La decisión de adoptarlo dependerá de si se necesita la capa de abstracción de lectura ya o se puede esperar a la madurez de la escritura en el ciclo 0.4.0.
