Turso, la empresa que durante el último año ha reimplementado SQLite en Rust manteniendo la compatibilidad con el formato de fichero y ampliando sus funciones, ha anunciado que va a hacer lo mismo con PostgreSQL. El proyecto saltó a la conversación general del sector a finales de julio y no es una traducción de consultas de Postgres a SQLite: la compañía plantea un núcleo de ejecución compartido sobre el que enchufar distintos dialectos SQL como si fueran frontends de compilador.
La idea de partida es que lo verdaderamente singular de SQLite no es su sintaxis, sino que compila SQL a un bytecode propio que ejecuta una máquina virtual, la VDBE. Si esa máquina virtual es el sustrato, argumenta Turso, nada impide compilar también PostgreSQL —y en el futuro MySQL o Redis— contra el mismo motor. De ahí la etiqueta que la compañía usa para describirse: «el LLVM de las bases de datos», un núcleo moderno y varios lenguajes de entrada por encima.
En la práctica, el compromiso declarado incluye el protocolo de red y la implementación del servidor, de modo que aplicaciones, ORMs y el cliente psql puedan conectarse sin cambios. Turso admite abiertamente que no persigue el 100 % de compatibilidad sino ser «suficientemente compatible», especialmente en las funciones más complejas del motor original. A cambio ofrece capacidades que Postgres no trae de serie, como vistas materializadas que se actualizan solas, y la posibilidad de ejecutar la base de datos embebida: en un fichero, en el navegador o en un dispositivo. La compañía sitúa la primera funcionalidad útil en meses, no en años, aunque reconoce que la cola larga de comportamientos requerirá bastante más tiempo.
El escepticismo es razonable. Reescribir SQLite es un objetivo acotado —motor pequeño, superficie bien delimitada, batería de pruebas pública—; PostgreSQL es un ecosistema de tres décadas con extensiones, tipos personalizados, planificador maduro y un catálogo interno del que dependen herramientas de terceros. Cualquier incompatibilidad silenciosa en el planificador o en el manejo de transacciones es un riesgo difícil de detectar en producción.
Aun así, la propuesta merece atención por lo que apunta más allá del propio proyecto. La consolidación de motores sobre un núcleo común es la misma tendencia que ya se ve en el almacenamiento con Apache Iceberg: separar el formato o el lenguaje de la implementación que lo ejecuta. Para equipos que hoy mantienen SQLite en el borde y PostgreSQL en el servidor, un núcleo único con dos dialectos reduciría la fricción operativa. Conviene seguirlo, pero por ahora es una apuesta arquitectónica, no una alternativa de producción.
Más en Dataprix: Bases de datos: arquitecturas, motores y rendimiento
Fuente: Blog de Turso
Contenido elaborado con asistencia de inteligencia artificial y revisado editorialmente por el equipo de Dataprix.