Un equipo de ingeniería construyó una red social llamada Chirp sobre un único archivo SQLite de 343 MB con 50.000 usuarios, un millón de publicaciones, casi 2,5 millones de relaciones de seguimiento y cinco millones de likes. Todo el backend es un proceso Node que lee y escribe directamente sobre chirp.db, sin servidor de bases de datos, sin contenedor y sin puerto 5432. La configuración productiva se reduce a cinco pragmas, todas las tablas declaradas STRICT siguiendo el consejo de Evan Hahn.
Las pruebas de carga, ejecutadas en un portátil Apple M1 con 8 núcleos, 16 GB de RAM y Node 22, arrojan cifras llamativas. Sobre HTTP real con 50 conexiones concurrentes, la lectura puntual de un post alcanza 51.427 solicitudes por segundo, el perfil de usuario 47.776 y la cronología (la consulta más pesada, con joins sobre la tabla de follows y conteo de likes) sostiene 3.543 req/s con p99 de 27 ms. En un escenario mixto del 95 % de lecturas y 5 % de escrituras se mantienen 3.654 req/s, equivalentes a 315 millones de solicitudes diarias en el endpoint más exigente.
El modo WAL (Write-Ahead Logging) resulta decisivo: con un escritor haciendo 1.000 escrituras por segundo, sirve 5,6 veces más lecturas que el antiguo journal de rollback (2.792 frente a 497 req/s) y mantiene el p99 en 4,4 ms frente a 133 ms, sin errores SQLITE_BUSY. Los commits de transacciones alcanzan 23.459 por segundo en escrituras individuales y 32.217 filas por segundo en lotes de 100.
El artículo también documenta los límites reales: las lecturas caen a unos 2.800 req/s cuando hay escrituras concurrentes por la invalidación de páginas mapeadas en memoria; SQLite solo admite un escritor global; y no existe failover nativo, por lo que casos con múltiples escritores contendiendo, réplicas de lectura, análisis sobre cientos de millones de filas o requisitos regulatorios de alta disponibilidad siguen siendo terreno de PostgreSQL.