turbolite

turbolite es un VFS de SQLite en Rust que sirve búsquedas puntuales y uniones directamente desde S3 con una latencia en frío inferior a 250 ms.

Este repositorio es un espacio de trabajo de Cargo con dos crates:

• turbolite — Biblioteca pura de Rust. VFS de SQLite con compresión a nivel de página, cifrado y escalonamiento a S3.
• turbolite-ffi — FFI C / extensión cargable + enlaces de idiomas (Python, Node.js, Go).

También ofrece compresión a nivel de página (zstd) y cifrado (AES-256) para eficiencia y seguridad en reposo, que pueden usarse por separado de S3.

Experimental. turbolite está en desarrollo activo y contiene errores. Ten cuidado.

El almacenamiento de objetos se está volviendo rápido. S3 Express One Zone ofrece GETs de un solo dígito en milisegundos y Tigris también es extremadamente rápido. La brecha entre el disco local y el almacenamiento en la nube se está reduciendo, y turbolite lo explota.

El diseño y el nombre están inspirados en el enfoque de turbopuffer de arquitectura despiadada en torno a las limitaciones del almacenamiento en la nube. El objetivo inicial del proyecto era superar los arranques en frío de más de 500 ms de Neon. Objetivo cumplido.

Si tienes una base de datos por servidor, usa un volumen. turbolite explora cómo tener cientos o miles de bases de datos (una por inquilino, una por espacio de trabajo, una por dispositivo), no quieres un volumen para cada una, y estás de acuerdo con una única fuente de escritura.

turbolite se distribuye como biblioteca de Rust, una extensión cargable de SQLite (.so/.dylib), y paquetes de idiomas para Python y Node.js, además de dependencias de Github para Go. Cualquier almacenamiento compatible con S3 funciona (AWS S3, Tigris, R2, MinIO, etc.). Es un VFS de SQLite estándar que opera a nivel de página, por lo que la mayoría de las funciones de SQLite deberían funcionar: FTS, R-tree, JSON, modo WAL, etc.

turbolite es parte del ecosistema más amplio de hadb. turbolite independiente es un VFS de almacenamiento con un escritor seguro; si deseas elección de líder HA más replicación continua de WAL, úsalo a través de haqlite-turbolite, que agrega HaQLite y walrust encima. Ese camino HA es aún muy experimental.

Si deseas contribuir a turbolite o encontrar errores, por favor crea una solicitud de extracción o abre un problema.

Rendimiento

Consulta	Tipo	Frío (S3 Express)	Frío (Tigris)
Publicación + usuario	búsqueda puntual + unión	86 ms	172 ms
Perfil	unión multíple (5 JOINs)	251 ms	479 ms
Quién-dio-like	búsqueda en índice + unión	206 ms	302 ms
Amigos mutuos	unión multíple búsqueda	19 ms	49 ms
Filtro indexado	escaneo de índice cubierto	79 ms	88 ms
Escaneo completo + filtro	escaneo completo de tabla	476 ms	532 ms

1 M publicaciones / 100 K usuarios (~1.5 GB almacenados) sin nada en caché, cada byte desde S3. EC2 c5.2xlarge + S3 Express One Zone (misma AZ, ~4 ms de latencia GET). Fly performance-8x + Tigris (~25 ms de latencia GET). Ambos: 8 vCPU dedicados, 16 GB RAM, 7 hilos de trabajo de precarga. Consulta Evaluación comparativa y El backend de almacenamiento importa.

Los puntos de referencia están organizados por nivel de caché (qué está ya en disco local cuando se ejecuta la consulta):

Nivel de caché	Qué está en caché	Qué se obtiene de S3	Cuándo ocurre
ninguno	nada	todo	Inicio fresco, caché vacía
interior	páginas interiores del árbol B	páginas de índice + datos	Primera consulta después de abrir conexión
índice	páginas interiores + de índice	solo páginas de datos	Operación normal de turbolite
datos	todo	nada	Equivalente a SQLite local

interior es el punto de referencia en frío más realista: las páginas interiores se cargan con avidez al abrir la conexión, por lo que cuando ejecutas tu primera consulta, ya están en caché. Las páginas de índice se precargan agresivamente en segundo plano en el primer acceso y puede que no estén listas aún.

Caché caliente (sobrecarga del VFS vs. SQLite simple)

100 K filas, Fly.io performance-2x (vCPU dedicado, NVMe, IAD):

Operación	SQLite	turbolite	Sobrecarga
Búsqueda puntual	145 K/s	73 K/s	2.0x
Escaneo de rango	8.8 K/s	8.3 K/s	paridad
Escaneo completo de tabla	56/s	60/s	paridad
INSERT	19 K/s	23 K/s	paridad
UPDATE por PK	40 K/s	27 K/s	1.5x
INSERT por lotes (en txn)	685 K/s	740 K/s	paridad

Las búsquedas puntuales tienen la mayor sobrecarga por página (~2x). Todo lo demás se acerca o supera la paridad. La arquitectura de caché libre de bloqueos significa que las lecturas concurrentes nunca bloquean las escrituras.

Costo de punto de control

Después	Local	S3 (RustFS en la misma región)
1 K inserciones	19 ms	38 ms
Lote de 10 K	17 ms	114 ms
1 K actualizaciones	9 ms	36 ms

Las escrituras siempre son a velocidad local. El costo de S3 solo ocurre en el punto de control. Números con RustFS en la misma región de Fly (~2 ms RTT). S3 Express One Zone sería comparable.

Inicio rápido

Python```bash

pip install turbolite

- [Comandos esenciales](#core-commands)
- [Mejoras](#improvements)
- [Configuración](#configuration)
- [Opciones](#options)
  - [Opciones de prioridad y severidad](#priority-and-severity-options)
  - [Ejecución de múltiples comandos en secuencia](#multi-command-execution-in-sequence)
  - [Uso de IA](#using-ai)
- [Demostración](#demo)
- [Instalación](#installation)
- [Requisitos](#requirements)
- [Licencia](#license)```python
import turbolite

conn = turbolite.connect("my.db", mode="s3",
    bucket="my-bucket",
    endpoint="https://t3.storage.dev")

conn.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)")
conn.execute("INSERT INTO users VALUES (1, 'alice', '[email protected]')")
conn.commit()

alice = conn.cursor().execute("SELECT * FROM users").fetchone()
print(alice[1])
>>> "alice"

Vea Instalación para Node, Go, Rust, modo solo local, y usando la extensión cargable .so directamente

Diseño

turbolite está diseñado para las restricciones de S3 en lugar de las restricciones del sistema de archivos. Cada decisión fluye de este modelo:

Restricción de S3	Implicación
Los viajes de ida y vuelta son lentos	Minimizar el número de solicitudes. Escribir por lotes, precargar lecturas de forma agresiva.
El ancho de banda es un cuello de botella	Maximizar la utilización del ancho de banda.
PUT y GET cobran por operación	Un GET de 64KB cuesta lo mismo que un GET de 16MB. Optimizar el número de solicitudes, no la eficiencia en bytes.
Los objetos son inmutables	Nunca actualizar en el lugar. Escribir nuevas versiones, intercambiar un puntero. Sin corrupción por escritura parcial.
El almacenamiento es barato	No optimizar para el espacio. Sobredimensionar, mantener versiones antiguas, dejar que la recolección de basura limpie más tarde.

Arquitectura