|

Turso: la reescritura de SQLite en Rust explicada

Si pasaste algo de tiempo en el rincón de GitHub que orbita SQLite, ya viste aparecer el nombre Turso por todos lados. La reescritura de SQLite en Rust que arrancó como proyecto paralelo llamado “Limbo” entró en beta en 2026 y se posiciona como la sucesora de libSQL, con soporte para escrituras concurrentes, búsqueda vectorial e I/O async nativo. ¿Vale la pena cambiarte hoy? Depende de para qué.

Turso es una base de datos SQL in-process escrita en Rust y compatible con SQLite, desarrollada por la empresa del mismo nombre. Corre dentro de tu aplicación (no como servidor daemon separado), habla el mismo dialecto SQL que SQLite y agrega funciones que SQLite nunca tuvo: múltiples escritores en paralelo, búsqueda de vectores para IA y entrada/salida asíncrona. Hoy está en beta.

En 30 segundos

  • Qué es: un motor SQLite reescrito de cero en Rust, in-process, compatible a nivel SQL.
  • Estado: beta en 2026, sucesor explícito de libSQL.
  • Su carta fuerte: BEGIN CONCURRENT con MVCC, o sea varios escritores a la vez, el dolor histórico de SQLite.
  • Para producción hoy: mejor libSQL (fork en C, ya maduro) más Turso Cloud.
  • Precio: el engine open source es gratis; lo que se paga es el servicio managed Turso Cloud.

¿Por qué reescribieron SQLite en Rust si ya funcionaba?

Acá viene la parte que confunde a todos, así que vale aclararla antes de tocar una línea de código. Hay tres cosas distintas con nombres parecidos, y mezclarlas es el error número uno en la comunidad. Esto se conecta con lo que cubrimos en nuestro artículo sobre integrando Turso en tu pipeline CI/CD.

  • libSQL: el proyecto original de la empresa, un fork de SQLite escrito en C. Está listo para producción y es lo que hoy hace andar a Turso Cloud.
  • Turso (el engine): la reescritura de SQLite en Rust, clean-room, que empezó como “Limbo”. Está en beta y se plantea como el sucesor de libSQL, no como un experimento de fin de semana.
  • Turso Cloud: el producto managed, la base como servicio. Corre sobre libSQL, con el engine en Rust entrando de a poco.

¿Y por qué tirar abajo algo que andaba? SQLite es excelente pero tiene un techo de diseño: un solo escritor por vez. Reescribirlo en Rust les dio la chance de meter concurrencia real, I/O async y memoria segura sin arrastrar 25 años de decisiones en C. Según el equipo de Turso en The New Stack, la idea no fue mejorar SQLite sino construir el motor que querían tener para la próxima década.

Turso vs SQLite vs libSQL: ¿cuál es la diferencia real?

La tabla de abajo es lo más útil que te llevás de toda la nota. Mirala con calma.

CaracterísticaSQLiteTurso (Rust, beta)libSQL (C)
LenguajeCRustC (fork)
Escritores concurrentesUno soloVarios (MVCC, BEGIN CONCURRENT)Uno solo
I/O asíncronoNo nativoSí (io_uring en Linux, WASM)Limitado
Búsqueda vectorialCon extensiónIntegradaIntegrada
Listo para producciónSí, desde hace décadasNo, beta
Compatibilidad SQLReferenciaCompatibleCompatible
turso reescritura sqlite diagrama explicativo

El renglón que importa es el segundo. Cualquiera que haya peleado con un database is locked en SQLite bajo carga sabe de qué hablo. Turso permite que varias conexiones escriban en paralelo usando MVCC (control de concurrencia multiversión), y eso cambia el tipo de aplicaciones que podés montar encima sin migrar a Postgres.

¿Cómo instalo y ejecuto Turso en mi máquina?

La instalación es directa, sin servidor daemon dando vueltas. Tenés dos caminos según tu sistema. Para más detalles técnicos, mirá nuestro artículo sobre automatizar tests de bases de datos.

  • Con script de instalación: corrés el instalador oficial vía curl y te deja la CLI lista en el PATH.
  • Con Homebrew (macOS/Linux): brew install tursodatabase/tap/turso y listo.

Después, el flujo básico es este: te registrás con turso auth signup, creás una base con turso db create mi-base y entrás al shell interactivo con turso db shell mi-base. Desde ahí escribís SQL como en cualquier cliente de SQLite. Si querés el engine Rust puro en tu proyecto, sumás el binding del lenguaje que uses: hay SDKs oficiales para Rust, JavaScript, Python y Go. La documentación vive en turso.tech y el código en el repo de GitHub.

¿Qué características nuevas trae el engine sobre SQLite?

Esta es la parte donde Turso deja de ser “SQLite pero en Rust” y se vuelve otra cosa.

  • Escrituras concurrentes con MVCC: abrís una transacción con BEGIN CONCURRENT y dejás que varios procesos escriban sin bloquearse entre sí.
  • I/O async nativo: usa io_uring en Linux y está pensado para correr en el navegador vía WASM, algo que con SQLite tradicional era un dolor de cabeza.
  • Búsqueda vectorial integrada: guardás embeddings y hacés consultas de similitud sin extensiones externas, ideal para RAG y features de IA.
  • Full-text search y CDC: búsqueda de texto completo y Change Data Capture para reaccionar a cambios en tiempo real.
  • Bases encriptadas de fábrica: cifrado nativo en disco, sin parches de terceros.

Ponele que estás armando un buscador semántico para un catálogo de productos. Antes tenías que pegar SQLite con una extensión de vectores, rezar para que compilara en tu plataforma y bancarte la fricción. Con Turso, el vector search ya está adentro. Eso sí: varias de estas funciones todavía cargan etiqueta de experimental, así que no las metas en algo que no podés dar vuelta fácil.

Conectar Turso con JavaScript y Python: ejemplo básico

La gracia es que el SQL es el mismo de siempre. Si ya sabés SQLite, no aprendés nada nuevo a nivel consultas. En Node.js, el patrón es importar el cliente, abrir la conexión con tu URL y token de entorno, y tirar tus CREATE TABLE, INSERT y SELECT como toda la vida. En Python es idéntico: instalás el binding, abrís la conexión, ejecutás. Los tipos de datos, la sintaxis y el comportamiento de las consultas siguen la línea de SQLite, con la salvedad de que el orden de resultados puede diferir si no ponés un ORDER BY explícito (más sobre esto en un segundo). Ya lo cubrimos antes en ejecutar Turso sin dependencias externas.

Si vas a desplegar esto en un VPS o servidor propio para tu app, podés alojar el backend en donweb.com y dejar la base corriendo in-process al lado de tu código, sin infraestructura de base separada.

¿Es Turso seguro para producción o sigue en beta?

Acá toca ser honesto. El engine en Rust está en beta y tiene asperezas reales que conviene conocer antes de enamorarte.

  • MVCC con límites: hoy no soporta índices bajo MVCC y carga la base completa en memoria, lo que lo hace inviable para datasets gigantes.
  • Orden de consultas distinto: sin ORDER BY, el orden de las filas puede no coincidir con el de SQLite. Si tu código asumía un orden implícito, se rompe.
  • Features experimentales: encriptación y computación incremental todavía tienen bordes ásperos.

La recomendación de la propia gente de Turso es clara: si lo que querés es una base SQLite-compatible managed andando hoy en producción, arrancá con libSQL más Turso Cloud, que es lo maduro. El engine en Rust es para probar el futuro, no para apoyar la facturación de tu empresa sobre él. Todavía.

¿Vale la pena migrar a Turso? Casos de uso ideales

¿Cuándo tiene sentido subirte ahora? Cuando el riesgo es bajo y la función nueva te resuelve algo concreto. Relacionado: garantizar privacidad de datos en producción.

  • Prototipos y side projects: donde un bug de beta te cuesta una tarde, no un cliente.
  • Apps con IA: si necesitás vector search para embeddings o RAG, lo tenés integrado.
  • Edge y navegador: el soporte WASM lo hace candidato para correr la base donde antes no podías.

¿Cuándo no? En sistemas críticos en producción hoy, o en escenarios con escrituras muy densas y sensibles a latencia, donde SQLite puro sigue siendo más rápido y predecible. El engine open source es gratis para experimentar; lo que se paga es el servicio managed Turso Cloud.

Qué está confirmado y qué no

  • Confirmado: Turso es una reescritura en Rust, está en beta, es sucesor de libSQL y soporta escrituras concurrentes, vector search e I/O async.
  • Confirmado: libSQL es el camino production-ready y Turso Cloud corre sobre él.
  • Pendiente: fecha de salida estable del engine Rust. No hay un GA anunciado con fecha firme.
  • Pendiente: soporte completo de índices bajo MVCC y madurez del cifrado nativo.

Errores comunes al empezar con Turso

  • Confundir los tres proyectos: mucha gente instala el engine beta creyendo que es lo que usa Turso Cloud. No. Para producción managed, es libSQL.
  • Asumir orden de filas sin ORDER BY: en SQLite “funcionaba igual”; en Turso el orden puede cambiar. Poné siempre tu ORDER BY.
  • Meter datasets enormes en MVCC: como carga la base en memoria, una base de varios GB te va a doler. Medí antes de comprometerte.
  • Tratar features experimentales como estables: la encriptación todavía tiene asperezas; no la uses como única capa de seguridad en algo serio.

Preguntas Frecuentes

¿Qué es Turso?

Turso es una base de datos SQL in-process escrita en Rust y compatible con SQLite, desarrollada por la empresa Turso. Corre dentro de tu aplicación sin servidor separado y agrega escrituras concurrentes, búsqueda vectorial e I/O asíncrono. En 2026 está en beta.

¿Cuál es la diferencia entre Turso y libSQL?

libSQL es un fork de SQLite escrito en C, listo para producción, y es lo que hace andar a Turso Cloud. Turso es la reescritura desde cero en Rust, todavía en beta, planteada como sucesor de libSQL. Para producción hoy, usá libSQL.

¿Cómo instalo Turso?

Instalás la CLI con el script oficial vía curl o con Homebrew (brew install tursodatabase/tap/turso). Después te registrás con turso auth signup, creás una base con turso db create y entrás al shell. No requiere un servidor daemon corriendo aparte.

¿Cuánto cuesta Turso?

El engine open source en sí es gratis; lo que se paga es el servicio managed de Turso Cloud.

¿Puedo usar Turso en producción ya mismo?

El engine en Rust está en beta y no se recomienda para sistemas críticos todavía. Para producción, la opción madura es libSQL más Turso Cloud. El engine nuevo conviene reservarlo para prototipos, side projects y apps que toleren bordes ásperos.

Conclusión

Turso es la apuesta más interesante que le pasó a SQLite en años: escrituras concurrentes y vector search resuelven dos cosas que el original nunca dio, y hacerlo en Rust les abre la puerta a edge y navegador. ¿La pega? Está en beta, con MVCC limitado y features experimentales. Si arrancás un side project o una app con IA, instalalo y jugá. Si tenés un sistema en producción facturando, quedate en libSQL más Turso Cloud y mirá de reojo cómo madura el engine. La dirección es clara, los tiempos todavía no.

Fuentes

Te puede interesar...