SQLite en producción: lo que Julia Evans aprendió al usarlo en la vida real

Julia Evans publica sus notas sobre SQLite: nada espectacular, pero todo muy útil para quien duda en ejecutar una aplicación real sobre ese pequeño archivo.

El caso concreto

Julia Evans — cuyos zines y artículos han educado a una generación de desarrolladores sobre los internals de Linux, HTTP, DNS — publicó el 17 de julio de 2026 en su blog jvns.ca un artículo titulado « Learning a few things about running SQLite ». No es ni un tutorial de introducción ni un panegírico religioso: es un cuaderno de campo de una persona que ha puesto SQLite en producción en su propio servicio y anota lo que le sorprendió. Un deleite.

Lo que aprendemos

No spoilearemos el artículo — léanlo, está en inglés pero es corto —, pero algunos puntos vuelven con frecuencia en los debates sobre SQLite en producción y merecen recordarse aquí para los curiosos:

1. Modo WAL: indispensable para la concurrencia

Por defecto, SQLite usa el modo de journal DELETE, donde las escrituras bloquean las lecturas. En WAL (Write-Ahead Logging), las lecturas ya no bloquean las escrituras y viceversa:

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL (en lugar de FULL) acepta perder como máximo la última transacción en caso de corte de alimentación brusco, a cambio de una ganancia masiva de rendimiento. Es lo que hace, entre otros, Litestream y la mayoría de los servidores SQLite modernos.

2. Una sola conexión escritora, múltiples lectoras

A diferencia de PostgreSQL, SQLite no paraleliza las escrituras. Un patrón clásico en Rust o Go: una sola conexión reservada para la escritura, un pool de conexiones para las lecturas. Es el modelo de la crate rusqlite combinada con deadpool-sqlite con esta separación, o de la librería Go mattn/go-sqlite3 con sql.DB configurado como SetMaxOpenConns(1) para la escritura.

3. Copias de seguridad en vivo: Litestream o LiteFS

Hacer una copia de seguridad de un archivo SQLite «a lo bruto» cuando una transacción está en curso es la mejor forma de obtener una copia corrupta. Dos herramientas reinan:

• Litestream (de Ben Johnson, también autor de BoltDB): replica en continuo hacia S3, Backblaze B2 o GCS. Streaming del WAL, restauración rápida.
• LiteFS (del mismo autor, ahora en Fly.io): va más allá, replicación multinodo con lectura desde cualquier réplica.

4. El verdadero límite de SQLite en 2026

SQLite aguanta sin pestañear decenas de miles de peticiones por segundo en un solo archivo, siempre que esté en modo WAL y bien indexado. El verdadero límite no es SQL, es el disco: NVMe local >> disco de red, EBS gp3 >> EFS. Muchos fallos de SQLite en producción vienen de haber puesto el archivo en un share de red (NFS en particular — SQLite lo desaconseja explícitamente en negrita en su documentación sqlite.org/faq.html#q5).

Para recordar

El punto de vista de Julia Evans, como siempre, es: probar, medir, escribir lo que se encuentra. Nada de «SQLite escala» ni de «necesitas PostgreSQL para cualquier cosa real». Solo: este comportamiento me sorprendió, esto es por lo que, esto es lo que cambié.

Para cualquier desarrollador que dude en sacar el pesado armamento relacional para una aplicación mono-servidor o un proyecto personal, este tipo de artículo vale por cien benchmarks sintéticos.