SQLite lleva décadas como la base de datos más desplegada del mundo: está en tu iPhone, en aplicaciones de escritorio, en sistemas embebidos. Su ventaja es la simplicidad. Su limitación histórica: funciona en local. Moverla a la nube sin sacrificar velocidad siempre fue un compromiso.
Turbolite propone que ese compromiso ya no es necesario. Es una VFS (Virtual File System) para SQLite escrita en Rust que sirve consultas directamente desde S3 —o cualquier almacenamiento compatible— con latencia cold por debajo de 250 ms. No es una base de datos nueva. Es una capa que pone SQLite sobre la nube como si fuera disco local.
¿Qué problema resuelve exactamente?
El escenario clásico de SaaS multi-tenant tiene un problema de base de datos: si alojas a cientos o miles de clientes, ¿cómo manejas sus bases de datos sin que cada una tenga su propio volumen de almacenamiento? Un volumen por tenant es caro. Una base compartida complica el aislamiento. SQLite por tenant en disco local tiene sentido pero no escala a producción en la nube.
Aprende IA con nosotros
Únete gratis a mi comunidad en Skool, donde compartimos noticias, tutoriales y recursos para seguir aprendiendo juntos.
👥 Únete gratis 🚀Turbolite apunta exactamente a eso: “Si tienes cientos o miles de bases de datos —una por tenant, por workspace, por dispositivo— no quieres un volumen para cada una.” La solución es usar S3 como capa de almacenamiento, pero hacer que las consultas sigan siendo rápidas.
¿Cómo logra latencias bajo 250 ms desde S3?
El problema de SQLite sobre S3 naïve es que cada lectura de página genera un request HTTP separado. SQLite usa un B-tree de páginas de 4 KB; un JOIN simple puede tocar decenas de páginas. En S3, cada request cuesta latencia. El resultado es inutilizable.
Turbolite lo resuelve con varias capas técnicas:
- Páginas de 64 KB en vez de 4 KB. Páginas más grandes significan menos requests por consulta. El “precio” de S3 por request es el mismo para 4 KB que para 64 KB.
- Page groups comprimidos con zstd. Agrupa 256 páginas en un solo objeto S3 (~16 MB comprimidos), con compresión seekable por frames. Un cache miss descarga solo el sub-chunk relevante (~256 KB), no el objeto completo.
- Interior pages precargadas al abrir conexión. Las páginas internas del B-tree se precargan al iniciar, así la primera consulta ya las tiene en caché local.
- Prefetch predictivo con introspección del query plan. Antes de ejecutar la consulta, intercepta el
EXPLAIN QUERY PLANde SQLite y lanza los fetches paralelos de todos los page groups necesarios. En un JOIN de cinco tablas, los cinco fetches van en paralelo desde el inicio.
Los benchmarks sobre 1M de filas (1.5 GB de datos) muestran latencias cold de 77 ms para point lookups con S3 Express (latencia ~4 ms por GET) y 259 ms sobre Tigris (~25 ms por GET). Para JOINs multi-tabla: 188 ms y 681 ms respectivamente. Nada está cacheado cuando corren estas mediciones.
Compresión y cifrado integrados
Turbolite agrega compresión zstd y cifrado AES-256 a nivel de página, no de archivo. Eso es diferente a la mayoría de soluciones similares que operan sobre el archivo completo. La ventaja: SQLite puede seguir usando FTS, R-tree, JSON y WAL mode normalmente. La compresión no bloquea la funcionalidad estándar.
El cifrado en S3 usa AES-256-GCM con nonces aleatorios por frame (autenticado, detección de tampering). El cifrado local usa AES-256-CTR. La rotación de claves re-cifra todos los objetos S3 sin bajar el servicio: es crash-safe porque los objetos viejos nunca se sobreescriben y el manifest es el punto atómico de commit.
Esto lo diferencia de proyectos como soluciones que usan SQLite localmente para memoria de agentes IA —donde la base vive en el mismo proceso— y apunta a casos donde el almacenamiento necesita ser remoto, durable y compartido.
¿Cuándo tiene sentido usarlo?
Turbolite es experimental y lo dice sin rodeos: “It is new and contains bugs. It may corrupt your data. Please be careful.” Dicho eso, los casos de uso tienen lógica:
- Multi-tenancy con SQLite: una base por cliente alojada en S3, sin gestionar volúmenes. Cada tenant tiene su entorno aislado.
- Workloads OLTP con muchos point lookups: el sweet spot técnico son consultas por ID con JOINs acotados. Full scans son más lentos.
- SaaS “serverless”: bases que duermen y se activan. El costo de cold start (50-200 ms) es aceptable si las consultas no son en tiempo real.
- Bases de datos de agentes IA: una base por agente, por conversación, por usuario. El modelo de “una DB por entidad” encaja con la arquitectura de agentes autónomos.
Lo que no resuelve: múltiples escritores concurrentes (un solo writer), WAL shipping (en roadmap), y cargas analíticas con full scans intensivos en máquinas pequeñas.
El ecosistema y las alternativas
Turbolite reconoce su deuda con proyectos anteriores: Litestream (WAL backup a S3), sql.js-httpvfs (pionero en SQLite sobre HTTP Range GETs), sqlite_web_vfs+sqlite_zstd_vfs (lo más cercano técnicamente, pero solo lectura). La diferencia clave frente a casi todos: soporta escrituras a S3, no solo lecturas.
En el contexto más amplio, proyectos como Kula —que intencionalmente evita bases de datos externas para observabilidad de servidores— apuntan a la misma filosofía: simplicidad operativa antes que infraestructura pesada. Turbolite va en dirección opuesta: no simplifica la infraestructura, sino que la hace más eficiente sin cambiar la DX de SQLite.
Por qué importa para SaaS en 2026
El encarecimiento de RAM (DDR5 subió 225% en cinco meses este año) y el costo de volúmenes de almacenamiento por tenant hacen que arquitecturas como Turbolite sean relevantes económicamente. Si puedes tener 10.000 bases de datos en S3 en vez de 10.000 volúmenes de disco, el ahorro es real.
La pregunta que Turbolite todavía no responde completamente es durabilidad: entre checkpoints, los datos viven solo en WAL local. Si la máquina muere, esas escrituras se pierden. Para bases críticas de producción eso es un bloqueante. Para casos de uso como configuración por tenant, historial de conversaciones o logs analíticos, el tradeoff puede ser aceptable.
Es un proyecto de un desarrollador, experimental, con advertencias de corrupción de datos. También es técnicamente sólido, con benchmarks reales, arquitectura bien documentada y bindings para Python, Node.js, Go y Rust. El tipo de proyecto que vale seguir de cerca antes de que se estabilice.
