SQLite no es una base de datos de juguete — y un creciente conjunto de aplicaciones en producción lo demuestra

SQLite es el motor de base de datos más desplegado que existe. Se ejecuta dentro de cada dispositivo Android, cada iPhone, cada navegador de escritorio, cada Mac y la mayoría de sistemas Windows. Se estima que hay más de un billón de bases de datos SQLite en uso activo. Y durante la mayor parte de su historia, la regla implícita en el desarrollo web ha sido: SQLite es suficiente para desarrollo y pruebas, pero migras a Postgres o MySQL antes de lanzar.

Esa regla está siendo desafiada activamente — no como una opinión contraria, sino por desarrolladores que ejecutan sistemas reales en producción y reportan resultados reales. El cambio es en parte filosófico y en parte técnico.

La objeción tradicional

El argumento estándar contra SQLite en aplicaciones web de producción se basa en la concurrencia. SQLite es una base de datos basada en archivos: todas las lecturas y escrituras afectan un solo archivo en disco, y aunque soporta múltiples lectores concurrentes, solo permite un escritor a la vez. En modo WAL (Write-Ahead Logging), habilitado desde 2010, los lectores y el único escritor no se bloquean mutuamente — pero sigues teniendo un solo escritor. Para aplicaciones con alta concurrencia de escritura, esto es una limitación dura.

La segunda objeción es operativa: si tu aplicación se ejecuta en múltiples servidores, no pueden compartir un archivo SQLite. Bases de datos distribuidas como Postgres sobre TCP/IP están diseñadas para esto; SQLite no. Esto hacía que SQLite fuera esencialmente inviable para aplicaciones web con escalado horizontal.

Ambas objeciones son reales. Ninguna es universal.

Lo que cambió: el ecosistema de replicación

En 2021, Ben Johnson lanzó Litestream — una herramienta Open Source que transmite el archivo WAL de SQLite a almacenamiento de objetos compatible con S3 en tiempo casi real. La propuesta: obtienes copia de seguridad automática externa con RPO de subsegundo, sin cambiar el código de tu aplicación ni migrar a una base de datos cliente-servidor. Litestream no resuelve la limitación de un solo escritor; resuelve el problema de recuperación ante desastres y respaldo que hacía que SQLite pareciera inseguro para producción. Para muchos casos de uso, esa es la preocupación más apremiante.

Fly.io llevó esto más lejos con LiteFS, un sistema de archivos distribuido que usa FUSE para interceptar escrituras de SQLite y replicarlas a nodos réplica. LiteFS te da un nodo primario que acepta escrituras y réplicas de solo lectura que lo siguen — similar a la replicación por streaming de Postgres, pero para SQLite. Las aplicaciones que pueden enrutar escrituras al primario y lecturas a cualquier réplica se benefician del escalado horizontal de lectura sin cambiar el motor de base de datos.

El esfuerzo más ambicioso es Turso, construido sobre libSQL — un fork del código base de SQLite que añade un protocolo de red, multi-tenencia y replicación en el borde. La propuesta de Turso es 'SQLite en el borde': cada usuario obtiene un shard de base de datos geográficamente cercano a él, eliminando la latencia de una base de datos central. La empresa recaudó 32 millones de dólares en una ronda Serie A en 2023. libSQL es Open Source; el servicio gestionado de Turso es el producto comercial. El servicio de base de datos D1 de Cloudflare usa una arquitectura similar, ofreciendo almacenamiento compatible con SQLite como primitiva serverless.

El argumento del rendimiento

Para aplicaciones donde la base de datos reside en la misma máquina que el servidor de aplicaciones — lo cual es cierto para un gran porcentaje de aplicaciones auto-alojadas y pequeñas o medianas — SQLite con modo WAL a menudo supera en Benchmark a Postgres o MySQL en cargas de trabajo OLTP intensivas en lectura. La razón es la eliminación de la latencia de red: una consulta local de SQLite no atraviesa una conexión TCP. El costo de un viaje de ida y vuelta de red a un servidor Postgres, incluso en localhost, es de unos pocos cientos de microsegundos. En volúmenes altos de consultas, esto se acumula.

El artículo COST de 2015 ('Scalability! But at what COST?') hizo un punto relacionado en el contexto del procesamiento distribuido de grafos: una sola máquina ejecutando código monohilo bien optimizado a menudo superaba a sistemas distribuidos como Hadoop para grafos que cabían en RAM. La idea se generaliza: los sistemas distribuidos tienen sobrecarga, y si tus datos caben en una máquina, puedes estar pagando esa sobrecarga sin beneficio.

El modo WAL de SQLite también está extremadamente bien optimizado para alta concurrencia de lectura. Los Benchmarks de Turso y desarrolladores independientes muestran consistentemente que SQLite maneja decenas de miles de lecturas por segundo en hardware modesto, dentro del rango de la mayoría de aplicaciones web en producción.

Quién lo está haciendo realmente

37signals — la empresa detrás de Basecamp y Hey — ha sido el defensor público más vocal. La publicación en blog de DHH en 2023 argumentando que SQLite con Litestream es suficiente para la mayoría de aplicaciones web generó una discusión significativa. 37signals usa un modelo de 'una base de datos por cliente' para parte de su infraestructura, donde la propiedad de un solo archivo por base de datos de SQLite se convierte en una ventaja: los datos de cada cliente están aislados en su propio archivo, y las copias de seguridad son trivialmente simples.

Muchos desarrolladores independientes y equipos pequeños han migrado a SQLite por razones similares: modelo operativo más simple, sin proceso de servidor de base de datos separado que gestionar, copia de seguridad trivial (copiar el archivo) y rendimiento que satisface sus necesidades. El auge de plataformas como Railway y Fly.io, que facilitan ejecutar SQLite persistente junto a una aplicación web, ha reducido aún más la barrera operativa.

Donde todavía no tiene sentido

La limitación de un solo escritor es un techo real. Las aplicaciones con rendimiento sostenido alto de escritura — pipelines de ingesta analítica, sistemas de trading de alta frecuencia, plataformas sociales con millones de operaciones de escritura simultáneas — realmente necesitan una base de datos que pueda distribuir escrituras entre múltiples nodos. SQLite no puede hacer esto de forma nativa, y las herramientas de replicación construidas a su alrededor no cambian el modelo de escritura fundamental.

Los conjuntos de datos muy grandes también presentan desafíos. SQLite soporta bases de datos de hasta 281 TB en teoría, pero el rendimiento práctico en bases de datos de más de unos pocos cientos de gigabytes se degrada. Las características de vacuum, autovacuum y particionamiento de Postgres son maduras y bien comprendidas a escala; los mecanismos equivalentes de SQLite son más simples y menos probados en tamaños grandes.

La regla general que surge de la comunidad: si tu QPS de escritura está por debajo de unos pocos miles por segundo y tu conjunto de datos cabe cómodamente en un solo disco, vale la pena evaluar seriamente SQLite con WAL. Si necesitas escrituras multiprimarias, replicación sincrónica entre centros de datos o seguridad a nivel de fila con jerarquías de roles complejas, Postgres sigue siendo la herramienta adecuada.

Lo que ha cambiado es el encuadre. SQLite no es un juguete. Es un motor de base de datos maduro, extensivamente probado, con más de dos décadas de uso en producción en contextos mucho más exigentes que la mayoría de aplicaciones web. La pregunta no es si SQLite es serio — es si las restricciones específicas de tu aplicación encajan en su modelo. Para un número creciente de sistemas en producción, así es.