SQLite Es la Base de Datos de Producción Que Ya Conoces (Solo Que Aún No Lo Sabes)

En enero de 2024, DHH — creador de Ruby on Rails, CTO de 37signals — tuiteó algo que incomodó a muchos administradores de bases de datos: "Estábamos probando ONCE #1 en una instancia grande de AWS y alcanzando 30.000 usuarios concurrentes en nuestras métricas. Mola bastante ver eso tirando de sqlite!" Dos años después, la tendencia que señaló se ha convertido en un movimiento a gran escala. Y nosotros lo hemos estado viviendo — 14+ productos corriendo sobre SQLite en el edge con Cloudflare D1. 5$/mes para la capa de base de datos.

La Apuesta de DHH: SQLite para Productos Reales

Cuando DHH probó ONCE Campfire (el chat de equipo autoalojado de 37signals) con 30.000 usuarios concurrentes usando SQLite, la respuesta de la comunidad fue predecible: "¿Pero puede manejar escrituras?" Su respuesta: sí, estaba escribiendo.

La conversación que siguió fue reveladora:

"¿Estos 30k usuarios concurrentes solo leen o también escriben en SQLite?" — @mistyHarsh

"Escribiendo." — @dhh

Cuando alguien apuntó que Ruby podría ser el cuello de botella, DHH aclaró que en realidad alcanzaron el máximo de IOPS contra SQLite en esa máquina — y quería repetir el test en hardware SSD Gen 5 para ir más allá. El cuello de botella no era el lenguaje ni el framework. Era la velocidad del disco.

¿Backups? "Solo backups periódicos que empaquetan tanto la DB sqlite como los archivos de Active Storage en un único archivo con el que puedes hacer lo que quieras." Sin replicación en streaming. Sin WAL shipping a S3. Copiar un archivo. Ya está.

Esto no es un experimento de juguete. Campfire es una app de chat en producción donde las escrituras concurrentes son constantes — mensajes, actualizaciones de presencia, notificaciones. DHH reconoció que el lock de escritura es real ("El lock definitivamente puede ser un problema, si no prestas atención") pero dijo que las optimizaciones que hicieron fueron "optimizaciones muy útiles de todos modos. ¡Así que no pasa nada!"

¿Por Qué SQLite? Los Números No Mienten

SQLite es la base de datos más desplegada del mundo. No Postgres. No MySQL. No MongoDB. SQLite. Corre en cada smartphone, cada navegador, cada Mac, cada dispositivo IoT. Existen más de 1 billón de bases de datos activas en todo el mundo.

Aquí está por qué la industria está convergiendo en ella también para workloads de servidor:

Factor	DB Tradicional	SQLite
Despliegue	Servidor separado, connection strings, auth	Un solo archivo. Se despliega con tu app
Latencia	Round-trip de red (1-10ms)	En proceso (~0.01ms por lectura)
Operaciones	Backups, replicación, failover, upgrades	Copiar un archivo. Ese es el backup
Coste (gestionado)	50-200+$/mes (RDS, PlanetScale, Neon)	0-5$/mes
Escalar lecturas	Read replicas, connection pooling	Replicar el archivo a nodos edge
Soporte SQL	Completo	Completo: window functions, CTEs, JSON, FTS5

Un colega me dijo una vez al conocer nuestro stack: "El problema es que la gente se va a asustar mucho si les dices que usarás SQLite para guardar sus datos en producción." Y tiene razón — hay una brecha de percepción. Pero esa brecha se está cerrando rápido a medida que más empresas demuestran que funciona.

La única limitación que todo el mundo menciona — escritor único — resulta estar bien para la mayoría de aplicaciones. DHH lo demostró con 30K usuarios concurrentes. Nosotros lo demostramos a diario con toda nuestra plataforma.

Nuestro Stack: 14+ Productos en D1 (SQLite en el Edge)

No ejecutamos SQLite en un solo servidor. Usamos Cloudflare D1 — SQLite distribuido globalmente a través de los 300+ data centers de Cloudflare. Cada consulta se ejecuta en el edge, cerca del usuario. Esto es lo que ejecutamos en una sola base de datos D1:

Producto	Qué Almacena D1	Migraciones
Cadences	Proyectos, tareas, logs de llamadas IA, workflows, usuarios	107+
CIMAD RIS	Registros de pacientes, citas, refs. DICOM	15+
GoViajes	Leads de viajes, reservas, interacciones IA	12+
NutriNen	Datos de nutrición infantil, planes de comida	8+
VOID	Estado del juego, datos de jugadores, narrativas IA	5+
Newsletter	Suscriptores de todas las orgs (tabla unificada)	1
Heartbeat	Métricas de salud, datos de bienestar, alertas	6+

Total: 150+ migraciones, una sola base de datos D1, 5$/mes. Los mismos datos en AWS RDS PostgreSQL costarían 50-150$/mes mínimo — y eso antes de añadir read replicas, connection pooling (PgBouncer) y almacenamiento de backups.

El Write Lock: Real Pero Exagerado

La objeción más común contra SQLite en producción es la limitación de escritor único. El modo WAL (Write-Ahead Logging) ayuda enormemente — las lecturas concurrentes continúan mientras ocurren las escrituras — pero sigues teniendo un escritor a la vez.

La visión de DHH es pragmática:

"El lock definitivamente puede ser un problema, si no prestas atención. Tuvimos que cambiar algunas cosas para asegurar que éramos más eficientes con las escrituras, pero al final esas fueron optimizaciones muy útiles de todos modos."

Nuestra experiencia es idéntica. Las optimizaciones que haces para la disciplina de escritura de SQLite — agrupar escrituras, mantener transacciones breves, evitar locks prolongados — son simplemente buenas prácticas de ingeniería que hacen que cualquier base de datos rinda mejor. Esto es lo que hacemos:

• Inserciones por lotes — En lugar de 100 INSERTs individuales, una transacción con 100 sentencias. 50-100x más rápido
• Transacciones rápidas — Entrar, escribir, salir. Sin llamadas a APIs ni inferencia IA dentro de una transacción
• Bases de datos separadas por preocupación — DHH mencionó "1 archivo de DB por servicio" para cosas como Solid Queue. Nosotros mantenemos D1 centrado en datos de aplicación, no colas de trabajo ni caching
• Escrituras asíncronas donde sea posible — Registrar el evento inmediatamente, procesarlo de forma asíncrona. El usuario no espera por la escritura de analytics

En la práctica, el write lock nunca ha sido nuestro cuello de botella. La latencia de red, los tiempos de respuesta de proveedores IA y las llamadas a APIs externas son órdenes de magnitud más lentos que cualquier espera del lock de SQLite.

D1: SQLite + Distribución Edge = Superpoderes

Lo que hace a D1 diferente de simplemente ejecutar SQLite en un VPS es la distribución edge. Tu base de datos no está en us-east-1 — está replicada a donde estén tus usuarios.

Usuario en Barcelona → Cloudflare Madrid edge → D1 read  (~2ms)
Usuario en São Paulo  → Cloudflare GRU edge    → D1 read  (~3ms)
Usuario en Tokio      → Cloudflare NRT edge    → D1 read  (~2ms)

vs. DB Tradicional:
Usuario en Barcelona → AWS us-east-1           → DB query (~80-120ms)

Para escrituras, D1 redirige al primario (que está en una única región), pero las lecturas — que son el 80-90% de la mayoría de workloads — se sirven localmente. Combinado con el zero cold start de Workers, nuestras respuestas API consistentemente caen en el rango de 5-15ms globalmente.

Y las herramientas son sólidas. D1 soporta:

• Migraciones vía Wrangler (wrangler d1 migrations apply)
• Viaje en el tiempo — consulta tu base de datos tal como estaba en cualquier momento de los últimos 30 días
• Branching — crea una copia de tu DB para testing sin afectar producción
• API HTTP — consulta desde cualquier lugar, no solo Workers

El Movimiento SQLite-Everywhere

No somos solo nosotros y DHH. La industria está convergiendo:

• Turso/libSQL — Fork de SQLite con modo servidor, réplicas embebidas, multi-tenancy. Desde 0$
• LiteFS de Fly.io — SQLite distribuido con replicación automática
• Cloudflare D1 — SQLite en el edge (lo que usamos nosotros)
• Litestream — Replicación streaming de SQLite a S3
• SQLite en Bun — Soporte SQLite integrado, sin driver necesario
• Expo SQLite — SQLite para React Native con capacidades de sincronización
• val.town, Notion, Plausible — Más empresas adoptando SQLite para producción

El patrón es claro: tomar el motor de base de datos más fiable y mejor testeado de la historia (SQLite tiene 100% de cobertura de ramas en su suite de tests — más de 92.000 casos de prueba), y resolver el problema de distribución en la capa de infraestructura. No reemplaces SQLite con una base de datos "cloud-native". Pon SQLite en la nube.

Cuándo NO Usar SQLite

No somos fanáticos de SQLite. Hay casos donde no es la elección correcta:

• Requisitos de multi-escritor — Si genuinamente necesitas múltiples procesos escribiendo simultáneamente a muy alto throughput, Postgres o MySQL son mejores
• Topologías de replicación complejas — Multi-primary, escrituras geo-distribuidas con resolución de conflictos requieren una base de datos distribuida
• Datasets muy grandes — D1 tiene un límite de 10GB por base de datos. Si necesitas terabytes, busca otra opción
• Analytics pesado — Workloads OLAP con JOINs masivos sobre tablas enormes favorecen almacenes columnares como ClickHouse o DuckDB

Pero aquí está la cuestión — la mayoría de aplicaciones no llegan a estos límites. La mayoría de apps son CRUD con algo de complejidad. Y para CRUD, SQLite es absurdamente rápido, absurdamente fiable y absurdamente barato.

El Argumento del Coste Solo Ya Es Suficiente

Servicio	Coste Mensual	Lo Que Obtienes
Cloudflare D1	5$	5M lecturas/día, 100K escrituras/día, 5GB almacenamiento
Neon (Postgres)	19$+	Tier comparable
PlanetScale (MySQL)	39$+	Tier comparable
AWS RDS (Postgres)	50-150$+	db.t3.micro + storage + backups
Supabase (Postgres)	25$+	Tier comparable

Ejecutamos 14+ productos, 150+ migraciones, múltiples tablas con millones de filas, consultas en tiempo real desde agentes IA y bots de voz, máquinas de estado de workflows y un sistema de newsletter sirviendo a múltiples organizaciones — todo por 5$/mes en costes de base de datos.

Incluso si SQLite fuese ligeramente menos capaz que Postgres (no lo es, para nuestro caso de uso), la reducción de coste de 10-30x por sí sola justifica la elección.

Conclusiones Clave

1. SQLite está listo para producción en workloads serios. DHH lo demostró con 30K escritores concurrentes. Nosotros lo demostramos a diario con 14+ productos. La era de "SQLite es para testing" ha terminado. El write lock existe, pero las optimizaciones que haces para manejarlo son simplemente buena ingeniería — escrituras por lotes, transacciones cortas, procesamiento asíncrono.

2. El edge lo cambia todo para SQLite. D1, Turso, LiteFS — estos proyectos resuelven la mayor limitación de SQLite (servidor único) distribuyendo lecturas globalmente. Tu base de datos está a una consulta de 2ms de cualquier usuario en la Tierra, no a un round-trip de 100ms a us-east-1.

3. El coste a nuestra escala es 10-30x menor que Postgres/MySQL gestionado. 5$/mes vs. 50-150$/mes. Para una startup o equipo pequeño, esa es la diferencia entre ser viable y quemar dinero en infraestructura. Cada dólar no gastado en hosting de base de datos es un dólar invertido en producto.

4. La historia de backups es elegantemente simple. Como dijo DHH: "Solo backups periódicos que empaquetan la DB sqlite y los archivos de Active Storage en un único archivo." Sin WAL shipping, sin replication lag, sin complejidad de point-in-time recovery. Copiar un archivo. Listo. D1 añade time travel por encima durante 30 días.

5. La industria está convergiendo en SQLite. Cuando DHH, Cloudflare, Fly.io, Bun y una lista creciente de empresas apuestan por SQLite para workloads de producción, no es una moda — es una corrección. El mercado sobreindexó en bases de datos distribuidas complejas cuando el 90% de las aplicaciones estarían mejor servidas por el motor de base de datos más testeado jamás escrito.