- Turso conectó un frontend compatible con Postgres a su núcleo de base de datos basado en Rust, ampliándolo con una estructura de LLVM de las bases de datos, donde un solo motor de ejecución procesa varios lenguajes de base de datos
- Parsea SQL de Postgres a un AST común y lo compila a bytecode VDBE; tras validar su viabilidad con pgmicro, lo fusionó en el árbol principal de código para convertirlo en la base oficial de desarrollo
- El núcleo existente soporta compatibilidad con archivos SQLite, escrituras concurrentes con MVCC, ejecución asíncrona, un sistema de tipos rico y vistas materializadas con actualización automática, y valida su confiabilidad con varias técnicas de prueba
- Está diseñado para ejecutarse embebido o como un solo archivo en navegadores, móviles y diversos dispositivos, mientras permite que aplicaciones existentes, ORM y
psqlse conecten mediante el protocolo wire de Postgres - En lugar de buscar una coincidencia del 100%, se enfoca en las funciones centrales más usadas para que la mayoría de las aplicaciones existentes se ejecuten sin cambios; evalúa aplicar WASM y capas de compatibilidad para extensiones y PL/pgSQL, y se desarrolla bajo licencia MIT
Por qué construir Postgres sobre Turso
- Turso es un núcleo de base de datos moderno escrito en Rust, y sobre él se está construyendo desde cero una base de datos compatible con Postgres
- El objetivo a largo plazo no es simplemente trasladar el Postgres existente a Rust, sino crear una nueva base de datos con una arquitectura moderna
- No usa un proceso separado por cada conexión
- Puede ejecutarse de forma embebida dentro del navegador
- Puede manejar una base de datos como un solo archivo
- Las vistas materializadas se actualizan automáticamente sin trabajo adicional
- Apunta a una estructura de compilación intercambiable que conecta varios frontends a un único núcleo estable
- SQLite es el primer frontend
- Postgres es el siguiente frontend oficial
- En el futuro también podrían agregarse frontends como MySQL, Redis o bases de datos experimentales
- El resultado actual no es un producto terminado, sino una base de desarrollo que ya se puede ejecutar
De una reimplementación de SQLite a un núcleo común de base de datos
- Turso comenzó como un proyecto para reimplementar por completo SQLite en Rust y con una arquitectura moderna, manteniendo compatibilidad de archivos para abrir y crear archivos SQLite
- Ya cuenta con funciones que van más allá del alcance de SQLite
- Soporta escrituras concurrentes mediante MVCC, como Postgres
- Ofrece un sistema de tipos rico similar al de Postgres
- Opera de forma totalmente asíncrona, lo que lo hace apto para ejecución nativa incluso en entornos restringidos como el navegador
- Como las vistas materializadas se actualizan automáticamente en tiempo real, no hacen falta tareas cron de
REFRESH MATERIALIZED VIEWni combinaciones de triggers
- Aunque se agregue el frontend de Postgres, los objetivos existentes de Turso y SQLite no cambian
- Se seguirá buscando compatibilidad completa con SQLite y ampliación de funciones para cargas de trabajo futuras
- Al implementar funciones necesarias, también se podrán usar pruebas de Postgres para acelerar el desarrollo
Confiabilidad y modelo de contribución abierta
- Para reproducir la solidez de SQLite, la confiabilidad se trata como una función del producto
- Se usan pruebas de simulación deterministas
- Se realizan pruebas con Antithesis
- También se aplican pruebas Oracle, fuzzing y métodos formales
- Turso cuenta actualmente con más de 260 colaboradores y opera con un modelo de contribución abierta (Open Contribution) en el que personas externas también pueden participar en la dirección del proyecto
- Busca un entorno al estilo del kernel de Linux, centrado en el código y en estándares de alta calidad, donde quienes contribuyen de forma sostenida también participan en las decisiones del proyecto
- También acepta contribuciones escritas por IA, pero deben tener calidad suficiente, y las personas deben revisar el código cuidadosamente y entender la arquitectura
La máquina virtual VDBE dentro de SQLite
- SQLite no es una capa única que ejecuta SQL directamente, sino que tiene una arquitectura de máquina virtual que compila el SQL del dialecto SQLite a bytecode VDBE y lo ejecuta
- VDBE no es bytecode de propósito general como JVM, .NET o WASM, sino que ofrece operaciones de alto nivel específicas de bases de datos, como
buscar un elemento en un B-tree - Este lenguaje de bytecode no tiene una especificación pública ni una interfaz modular, pero existe realmente dentro de SQLite, y Turso adopta el mismo diseño
- Para validar la generalidad del VDBE de Turso, se convirtió Doom con un pequeño compilador de C a VDBE
- Se compiló el motor real de Turso a WASM y se ejecutó el bytecode VDBE de Doom en una pestaña del navegador
- Doom se ejecuta de la misma manera en que la base de datos procesa un
SELECT - Cada frame se trata como una fila de resultado
- Las áreas de memoria se representan como blobs que pueden leerse y escribirse
- La implementación puede verse en el repositorio turso-vdbe-doom-example
Estructura de compilación del frontend de Postgres
- Los intentos anteriores de combinar SQLite y Postgres dependían principalmente de una traducción en la capa de consultas, convirtiendo consultas Postgres en consultas SQLite debido a la estructura monolítica de SQLite; las diferencias en el comportamiento externo de ambas bases de datos generaban un gran desajuste de impedancia
- Internamente, la mayoría de las bases de datos SQL realizan operaciones básicas similares alrededor de B-trees y conjuntos de índices
- Hay diferencias claras entre las estructuras de almacenamiento de Postgres y SQLite
- Postgres coloca las filas en archivos heap y usa índices B-tree separados, versiones de tuplas, TID y vacuum
- SQLite agrupa los datos en B-trees
- Estas diferencias surgen principalmente de cómo se disponen los bytes en disco, y las operaciones necesarias para Postgres pueden representarse con el VDBE existente o soportarse extendiendo sus instrucciones
- En la nueva estructura, se puede intercambiar el frontend de la base de datos
- Se parsea el lenguaje de Postgres a un AST común
- Se compila el AST a bytecode de Turso
- El núcleo común de Turso ejecuta el bytecode
- El experimento inicial que validó la posibilidad se hizo con pgmicro, y los resultados se fusionaron en el árbol principal de código de Turso para convertirlo en un proyecto oficial
Formas de ejecución y escenarios de uso
- El objetivo es ofrecer el mismo SQL de Postgres y el mismo comportamiento de base de datos en varias formas, sin servidor
- Ejecutar una base de datos realmente compatible con Postgres en una pestaña del navegador
- Que un agente cree una base de datos nueva por usuario y gestione cada una como un solo archivo
- Que una aplicación local-first descargue datos de Postgres como un solo archivo y luego los vuelva a sincronizar
- Ejecutarlo de forma embebida, como SQLite, en teléfonos móviles y diversos dispositivos
- También se planea soportar en Turso/Postgres la función de sincronizar una base de datos Turso existente a un archivo local
- Además de ejecución embebida y en un solo archivo, también incluye protocolo wire e implementación de servidor, para que aplicaciones existentes, ORM y
psqlpuedan conectarse - En el corto plazo, los frontends oficiales que el equipo de Turso desarrollará directamente serán SQLite y Postgres; la estructura se abrirá para que colaboradores externos puedan crear otros frontends
Cómo ejecutarlo actualmente y cómo participar
- Todavía no hay paquetes distribuidos, pero se puede compilar y ejecutar directamente desde el código fuente
cd postgres/cli && cargo run - El frontend de Postgres no se desarrolla en un repositorio separado, sino dentro del árbol de código de Turso como frontend oficial desde el primer día
- El desarrollo y las contribuciones se realizan en el repositorio de Turso en GitHub
Objetivos y límites de compatibilidad
- Dada la naturaleza de Postgres, mucho más compleja que SQLite, la compatibilidad del 100% no se toma como objetivo obligatorio
- Se enfoca en soportar suficientemente las funciones centrales y las más usadas para que la mayoría de los usuarios pueda ejecutar sus aplicaciones sin modificarlas
- Cuando las funciones modernas entren en conflicto con la compatibilidad 1:1 perfecta, se decidirá caso por caso
- Las vistas materializadas de Turso se actualizan automáticamente en tiempo real
- No está definido si se implementará por separado el método tradicional sin actualización automática solo para lograr compatibilidad completa
- A medida que aumente el alcance funcional, Turso/Postgres podría acercarse más a una base de datos propia que a una copia de Postgres
Uso de IA y velocidad de desarrollo
- Se usan activamente herramientas de IA, pero no se omiten la revisión de código ni la comprensión de la arquitectura
- En componentes críticos como una base de datos, se considera que las herramientas de IA todavía no han alcanzado el nivel de reemplazar la responsabilidad de verificación
- La velocidad por commit puede ser menor que con un enfoque de ejecutar Fable 24 horas al día, pero se parte de un núcleo de base de datos que ya funciona y está ampliamente probado
- En lugar de cambiar rápido y romper el sistema, se elige implementar correctamente aunque sea más lento
- Completar todas las funciones requerirá tiempo, y algunas funciones deberán pasar por un proceso de desarrollo largo hasta que la arquitectura adecuada esté establecida
PL/pgSQL y extensiones
- PL/pgSQL no es un elemento imposible de implementar, sino un lenguaje procedural; sin embargo, es más probable que se ofrezca un lenguaje procedural separado y una capa de compatibilidad en lugar de reimplementarlo tal cual
- Se obtuvo una prueba de concepto para cargar algunas extensiones de Postgres en contenedores WASM
- Las extensiones que solo usan símbolos provistos por el contenedor WASM pueden cargarse de forma arbitraria
- Hay una pérdida de rendimiento por la ejecución en WASM
- Aún no es un diseño definido como final
- Se considera indeseable un sistema de extensiones que permita ejecutar código arbitrario sin restricciones
- Es posible que algunas extensiones no puedan soportarse, pero se cree que muchas podrán cargarse si se compilan a WASM
Calendario estimado y estrategia open source
- En vez de crear una base de datos desde cero, se parte de un núcleo que ya funciona, está probado y comparte buena parte de su estructura interna con Postgres
- Implementar todas las funciones de Postgres podría llevar mucho tiempo, pero se espera poder ofrecer en unos meses un subconjunto de funciones lo suficientemente amplio como para ser útil en la práctica
- Los dos desarrolladores principales tienen actualmente alrededor de 44 años y pueden seguir desarrollando durante al menos 20 años más, por lo que no hay prisa por completar todas las funciones
- La velocidad y el alcance reales del desarrollo dependerán mucho de las contribuciones de la comunidad
- Cuando se implementó soporte multiproceso para el dialecto SQLite, el equipo no tenía equipos Windows, así que se excluyó la implementación para Windows
- Un desarrollador externo que usaba mucho Turso se interesó y completó el soporte para Windows en menos de una semana
- Los frontends experimentales pueden desarrollarse fuera del árbol de código, pero el frontend oficial de Postgres aplicará la misma licencia MIT que Turso
1 comentarios
Comentarios en Lobste.rs
Me parece que casi todas las bases de datos SQL compilan las consultas para una máquina virtual (VM).
En ese sentido, señalar solo a SQLite como algo especial se ve un poco raro.
En cambio, SQLite compila las consultas a bytecode imperativo con variables y bucles.
Como desarrollador de pgwire, me alegra que Turso vuelva a usar pgwire para una base de datos compatible con PostgreSQL.
Me da curiosidad saber por qué la empresa decidió que necesitaba un cambio de rumbo.
Me pregunto si ya terminaron la reimplementación de SQLite o si la abandonaron.
https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next
Parece que siguen manteniendo ese objetivo, mientras agregan otros frontends en el camino.
Es un artículo muy interesante, y da vergüenza que lo hayan reportado injustamente.
De ninguna manera es “off-topic” ni “spam”, y no entiendo en absoluto por qué lo reportaron así.
Tal vez lo dieron por basura generada por IA solo porque el texto tiene un guion; de verdad siento que la gente está perdiendo la cabeza.
La cultura de reportes en este sitio se volvió espantosa; espero que los moderadores hagan algo. Si bloquean a unas cuantas personas que reportan de mala fe, quizá el resto se modere.
Desde hace tiempo me incomodaba la actitud de Turso de presentarse como el sucesor de SQLite, y por eso hace años decidí ni siquiera probar su software.
Pero si ofrecen vistas materializadas con actualización automática rápidas y baratas fuera de SQL Server, quizá termine usándolo de todos modos.