SQLite manejó 315 millones de solicitudes diarias en un portátil

Un único archivo SQLite soportó una red social con 50,000 usuarios, 1,000,000 publicaciones, 2,498,799 seguimientos y 4,999,764 “likes”—todo en 343MB—y aun así sirvió la página más pesada de la app a 3,654 solicitudes por segundo en un portátil Apple M1.

Ese benchmark proviene de la app de prueba de DB Pro, Chirp, que utilizó Node 22, better-sqlite3 y SQLite 3.49.2. Cada tabla se configuró como STRICT, y el backend se ejecutó como un único proceso de Node que hablaba directamente con chirp.db, sin servidor de base de datos separado.

Con HTTP real y 50 conexiones concurrentes, los resultados fueron:

• GET /post/:id: 51,427 solicitudes/s
• GET /u/:handle: 47,776 solicitudes/s
• GET /timeline/:id: 3,543 solicitudes/s
• Carga mixta con 95% lecturas de timeline, 5% escrituras: 3,654 solicitudes/s

La consulta pesada de timeline une las relaciones de seguimiento con las publicaciones, ordena por tiempo y cuenta los likes. DB Pro dice que eso equivale aproximadamente a 315 millones de solicitudes al día para el endpoint más exigente.

En benchmarks de consultas crudas, SQLite fue aún más rápido, incluyendo 232,011 ops/s para lecturas puntuales y 23,459 transacciones de escritura comprometidas por segundo al insertar una publicación. Los inserts por lotes alcanzaron 32,217 filas/s.

Recomendado

Biren presenta supernodo de IA con 1,024 aceleradores

El modo WAL marcó la mayor diferencia

El argumento principal del artículo es que las quejas antiguas sobre el bloqueo en SQLite describen mayormente el modo rollback journal, no Write-Ahead Logging (WAL). En pruebas con siete hilos lectores ejecutando consultas de timeline junto a un escritor:

• En modo WAL, las lecturas se mantuvieron en 2,792 lecturas/s con 1,000 escrituras/s, con 4.40 ms de latencia p99 y cero errores SQLITE_BUSY.
• En modo journal DELETE, la misma configuración cayó a 497 lecturas/s, con 133.85 ms p99 y lecturas en el peor caso de hasta 794 ms.

Con un escritor funcionando a tope, WAL aún entregó 2,854 lecturas/s, mientras que el modo DELETE cayó a 227 lecturas/s.

Dónde SQLite deja de ser suficiente

La publicación es clara respecto a los límites. Una vez que comienzan las escrituras, las lecturas dejan de escalar limpiamente porque los commits invalidan páginas mapeadas en memoria y las ventajas de caché caliente desaparecen. La cifra limpia solo-lectura de 17,581 lecturas/s cayó a alrededor de 2,800 lecturas/s en cargas mixtas.

También hay límites arquitectónicos mayores:

• Un solo escritor a nivel global: las escrituras se encolan en vez de ejecutarse en paralelo
• Una sola máquina: sin conmutación por error automática ni réplicas
• Menos adecuado para equipos que necesitan analítica sobre cientos de millones de filas, muchos escritores en contención o características avanzadas de Postgres basadas en extensiones

DB Pro también estimó el rendimiento en instancias cloud de bajo coste, argumentando que esta carga está mayormente limitada por la velocidad de un solo núcleo y por tener suficiente RAM para mantener la base de datos en la caché de páginas. Su estimación más básica, una máquina DigitalOcean Basic 1 vCPU / 2GB a alrededor de $12/mes, aun así dio aproximadamente 110 millones de solicitudes de timeline al día.

El consejo práctico es simple: priorizar un buen rendimiento de un solo núcleo, suficiente RAM para contener la base de datos y NVMe local—no almacenamiento conectado en red.

El punto más amplio de la publicación tiene menos que ver con SQLite y más con las costumbres de ingeniería en startups: muchas apps pequeñas aprovisionan Postgres mucho antes de tener tráfico suficiente para justificar la complejidad. Para DB Pro, el valor predeterminado más seguro es directo: «Envía el archivo.»