SQLite estaba destinada a ser una base de datos de juguete. Resulta que impulsa la mitad de Internet.

Hay aproximadamente un billón de bases de datos SQLite en uso activo en la actualidad. Un billón. Cada iPhone y cada dispositivo Android lleva varias. Cada instalación de Chrome, Firefox, macOS y Windows las integra. Adobe, Airbus, Apple, Google y el ejército de Estados Unidos distribuyen software con SQLite en su interior. Por puro volumen de implementaciones, es el motor de base de datos más utilizado jamás creado — y durante la mayor parte de sus 26 años de historia, los desarrolladores lo trataron como una biblioteca de conveniencia para datos locales, no como una base de datos de producción para servidores.

Eso cambió entre 2022 y 2026. Un conjunto de nuevas herramientas resolvió la limitación clásica de SQLite del lado del servidor, y un número creciente de aplicaciones de producción abandonaron silenciosamente Postgres, MySQL y Redis en favor de un único archivo .db. Aquí te explicamos por qué — y si tiene sentido para tu proyecto.

Qué es realmente SQLite (y qué no)

SQLite no es un servidor de base de datos. Es una biblioteca en C — aproximadamente 150,000 líneas de código C bien probado — que se enlaza directamente en tu aplicación. Toda la base de datos reside en un único archivo en el disco. No hay socket de red, ni capa de autenticación, ni pool de conexiones, ni un proceso separado que iniciar o monitorizar. Tu aplicación lee y escribe el archivo directamente, en el mismo proceso.

Richard Hipp creó SQLite en el año 2000 para usarlo en destructores de misiles guiados de la Marina estadounidense, donde la fiabilidad del almacenamiento de datos embebido importaba más que la concurrencia multiusuario. La decisión de diseño fue intencionada: simplicidad, fiabilidad y administración cero a costa de escrituras concurrentes. El formato del archivo es estable desde 2004, y la documentación de SQLite de 2024 se compromete explícitamente a mantener ese formato "para siempre" — una garantía inusualmente firme en el mundo del software.

La consecuencia más importante del diseño en proceso: latencia de red cero. Una consulta que tardaría 1-2 ms de ida y vuelta a una instancia remota de Postgres tarda microsegundos en SQLite. Para aplicaciones con muchas lecturas que se ejecutan en la misma máquina que la base de datos, la diferencia de rendimiento es real.

El renacimiento del lado servidor

La historia de SQLite en el servidor comienza con una limitación: las escrituras se serializan. Solo un escritor puede mantener el bloqueo de la base de datos a la vez. En el modo de journal predeterminado, los lectores también bloquean a los escritores. Para una aplicación web multiusuario, esto parece fatal.

Cuatro herramientas cambiaron el panorama entre 2022 y 2023:

• Cloudflare D1 (2022): Cloudflare construyó un producto SQLite serverless sobre Cloudflare Workers, distribuyendo bases de datos SQLite a ubicaciones edge globales. D1 usa el modo WAL (Write-Ahead Logging) de SQLite y los Durable Objects de Cloudflare para la consistencia. Llevó SQLite al edge con una interfaz SQL familiar y precios por lectura/escritura por fila.
• Fly.io LiteFS (2022): LiteFS es un sistema de archivos basado en FUSE que intercepta las escrituras de SQLite y las replica a nodos seguidores mediante un registro de transacciones. Permite ejecutar un nodo primario SQLite y múltiples réplicas de solo lectura — un patrón antes imposible con SQLite vanilla. Fly.io usa LiteFS internamente para su propia infraestructura.
• Turso (2023): Turso bifurcó SQLite en libSQL, una base de datos compatible con SQLite de código abierto con replicación integrada, soporte para API HTTP y distribución edge. El plan gratuito de Turso incluye 500 bases de datos, lo que hace que las arquitecturas multitenencia con una SQLite por usuario sean esencialmente gratuitas para prototipar.
• Bun con SQLite integrado (2023): Bun lanzó bun:sqlite, un driver nativo de SQLite integrado directamente en el runtime Bun. Los benchmarks muestran que se ejecuta aproximadamente 3 veces más rápido que better-sqlite3 para cargas de trabajo típicas, eliminando la necesidad de un paquete npm separado para la mayoría de los casos de uso.

Cada una de estas herramientas aborda una carencia específica: D1 maneja la distribución edge, LiteFS maneja la replicación, Turso maneja ambas más una API HTTP, y Bun maneja la ergonomía del desarrollador. Juntas convirtieron a SQLite de una curiosidad local en una opción creíble para el lado del servidor.

Novedades en SQLite 3.45+

Mientras las herramientas del ecosistema maduraban, SQLite en sí mismo incorporó mejoras significativas en versiones recientes:

• SQLite 3.45 (enero de 2024): Introdujo jsonb — un formato binario de almacenamiento JSON que mantiene los datos JSON en una representación binaria interna en lugar de analizar texto en cada acceso. Los benchmarks muestran que las operaciones con jsonb son hasta 10 veces más rápidas que las equivalentes con JSON en texto para estructuras anidadas complejas. Esta misma versión añadió soporte para JSON5, permitiendo sintaxis JSON relajada (comentarios, comas finales, cadenas con comillas simples) en las funciones JSON.
• SQLite 3.46 (mayo de 2024): Añadió mensajes de error sustancialmente mejorados con más contexto sobre qué salió mal y dónde. PRAGMA optimize se mejoró para ejecutarse más eficientemente en aplicaciones de larga duración — ahora acepta una máscara de bits para controlar qué optimizaciones aplicar, útil para aplicaciones que quieren ejecutarlo periódicamente en lugar de al cerrar la conexión.
• SQLite 3.47+ (finales de 2024 — 2025): Entregó mejoras en la estimación de costos del planificador de consultas para joins complejos, reduciendo los casos en que se elegían planes de consulta subóptimos para tablas grandes. La familia de funciones UNIXEPOCH() se amplió con nuevos modificadores para operaciones aritméticas de fechas más flexibles directamente en SQL.

La adición de jsonb merece énfasis. JSON se ha convertido en un tipo de datos de primera clase en las aplicaciones modernas, y el almacenamiento JSON basado en texto de SQLite anterior implicaba ciclos repetidos de análisis/serialización. Cambiar a columnas jsonb en un esquema con cargas de trabajo JSON pesadas es una ganancia de rendimiento con esfuerzo casi nulo: cambia el tipo de columna, reconstruye, listo.

Modo WAL y concurrencia — los números

La objeción más común a SQLite en el servidor es la concurrencia. La respuesta es el modo WAL, activado con un solo pragma: PRAGMA journal_mode=WAL;

En modo WAL, la base de datos mantiene un archivo de registro de escritura por adelantado separado junto al archivo principal de la base de datos. Los escritores agregan al WAL; los lectores leen del archivo principal más cualquier entrada comprometida del WAL. El resultado: los lectores nunca bloquean a los escritores, y los escritores nunca bloquean a los lectores. Múltiples lectores concurrentes operan en paralelo sin contención de bloqueos. Solo las escrituras se serializan entre sí — y para la mayoría de las aplicaciones web, las escrituras son una fracción pequeña del total de consultas.

Benchmarks medidos en un MacBook M2 con almacenamiento NVMe:

• SQLite modo WAL, lecturas concurrentes: ~130,000 lecturas/seg
• SQLite modo WAL, escrituras secuenciales: ~35,000 escrituras/seg
• Postgres en el mismo hardware (con sobrecarga de conexión): ~40,000 lecturas/seg

El rendimiento de lectura de SQLite en modo WAL es aproximadamente 3 veces mayor que el de Postgres en hardware comparable — porque no hay comunicación entre procesos. La base de datos está en el mismo proceso que la aplicación; cada consulta es una llamada a función, no un viaje de ida y vuelta por la red.

Las escrituras cuentan una historia más matizada. SQLite serializa las escrituras, por lo que una aplicación con muchas escrituras que alcance 35,000 escrituras/seg saturará al único escritor. Postgres, con su arquitectura de múltiples escritores, escala las escrituras horizontalmente. Si tu aplicación está haciendo 10,000+ escrituras concurrentes por segundo desde instancias de aplicación separadas, SQLite es la elección incorrecta. Si estás haciendo 500 escrituras/seg con 50,000 lecturas/seg, SQLite gana por un margen amplio.

Cuándo SQLite es la elección correcta

La decisión es una cuestión de carga de trabajo, no de prestigio:

• Cargas de trabajo con muchas lecturas y pocas escrituras ✓ — El rendimiento de lectura de SQLite es excepcional; las escrituras serializadas rara vez son el cuello de botella
• Despliegues en una sola región ✓ — Un escritor primario, baja latencia, operaciones simples
• Despliegues en el edge y embebidos ✓ — Infraestructura cero, funciona en cualquier lugar donde se ejecute un proceso
• Conjuntos de datos pequeños o medianos ✓ — SQLite soporta bases de datos de hasta 281 TB teóricamente; en la práctica, por debajo de 100 GB es el punto óptimo donde las operaciones a nivel de archivo siguen siendo rápidas
• Aplicaciones que necesitan infraestructura cero ✓ — Sin servidor de base de datos que provisionar, parchear o monitorizar
• Escrituras de alta concurrencia desde múltiples procesos ✗ — Las escrituras serializadas se convierten en el cuello de botella; usa Postgres o MySQL
• Escrituras primarias en múltiples regiones ✗ — SQLite tiene un solo escritor; la activa-activa multirregión requiere una base de datos distribuida
• Búsqueda de texto completo a escala ✓/✗ — La extensión FTS5 es capaz para cargas de trabajo moderadas; para millones de documentos con ranking de relevancia complejo, es mejor un motor de búsqueda dedicado

Las herramientas que hacen práctico a SQLite en el servidor

Más allá de la base de datos en sí, el ecosistema ha llenado los vacíos operativos:

• Turso: SQLite distribuido con la bifurcación libSQL, API HTTP y WebSocket, replicación a múltiples ubicaciones edge, réplicas embebidas (SQLite local que se sincroniza con una base de datos Turso remota). Plan gratuito: 500 bases de datos, 1000 millones de lecturas de filas/mes.
• LiteFS: Replicación de SQLite basada en FUSE de Fly.io. Intercepta las operaciones del sistema de archivos para capturar el registro de escritura por adelantado de SQLite y transmitirlo a las réplicas. Grado de producción, usado internamente por Fly.io. Requiere un entorno Linux con soporte FUSE.
• Litestream: Replicación en streaming de SQLite a S3, R2, GCS o Azure Blob Storage en un solo binario. Se ejecuta como un proceso sidecar junto a tu aplicación, replicando cada frame del WAL casi en tiempo real. Tiempo de restauración desde S3: menos de 30 segundos para una base de datos de 10 GB. Costo casi nulo — solo pagas por almacenamiento S3 y salida de datos.
• Cloudflare D1: SQLite serverless en el edge dentro de la plataforma Cloudflare Workers. Replicación de lectura transparente a aproximadamente 300 ubicaciones edge. Precios: $0.001 por millón de lecturas de filas, $1.00 por millón de escrituras de filas, 5 GB de almacenamiento en el plan gratuito.
• bun:sqlite de Bun: Integrado directamente en el runtime Bun, sin necesidad de npm install. Usa el SQLite del sistema o incluye el suyo propio. Consistentemente obtiene benchmarks ~3 veces más rápidos que better-sqlite3 para cargas de trabajo de consultas síncronas, gracias a una integración más estrecha con V8/JSC y una sobrecarga FFI reducida.

El caso de un SaaS con 100k usuarios sobre SQLite

El patrón arquitectónico más interesante que ha surgido del renacimiento de SQLite es una base de datos por usuario (o por inquilino). En lugar de una única base de datos compartida con columnas user_id por todas partes, cada usuario recibe su propio archivo .db.

Las ventajas son significativas: aislamiento completo de datos, copia de seguridad y restauración triviales por usuario, riesgo cero de fugas de datos entre inquilinos debido a errores en SQL, y la capacidad de mover bases de datos de usuarios individuales entre servidores sin coordinación. Eliminar los datos de un usuario es una sola llamada unlink().

Este patrón se ha usado silenciosamente en producción durante años. Los casos documentados incluyen aplicaciones SaaS con más de 50,000 usuarios activos que funcionan enteramente sobre SQLite con Litestream para copia de seguridad — sin Postgres, sin Redis, sin equipo de infraestructura de base de datos dedicado. Toda la capa de base de datos cabe en un solo directorio de archivos .db, respaldados continuamente en S3 por céntimos al mes.

El patrón escala bien hasta que necesitas consultas entre usuarios — análisis que agreguen datos de todos los usuarios, por ejemplo. En ese punto, o mantienes una base de datos de análisis separada o aceptas que SQLite por usuario no es el modelo adecuado para esa consulta.

En resumen

SQLite nunca fue un juguete. Siempre fue una compensación diferente: simplicidad, fiabilidad y rendimiento para cargas de trabajo de un solo escritor, a costa de escrituras concurrentes y acceso multiproceso. El ecosistema 2022-2026 — Turso, Litestream, LiteFS, Cloudflare D1, Bun — no cambió las compensaciones de SQLite. Construyeron las herramientas operativas que hacen que esas compensaciones sean aceptables para aplicaciones de servidor en producción.

Para una aplicación web con muchas lecturas que se ejecuta en una sola región, SQLite en modo WAL superará a Postgres en el mismo hardware, costará menos de operar y no requerirá administración de base de datos. Para una aplicación con muchas escrituras y múltiples escritores concurrentes entre regiones, Postgres sigue siendo la herramienta adecuada. El error es tratarlo como una cuestión de prestigio en lugar de una cuestión de carga de trabajo — SQLite ha ejecutado más software, en más dispositivos, de manera más fiable, que cualquier otra base de datos en la historia. Simplemente no necesita un servidor para hacerlo.