SQLite se está comiendo el mundo

La Base de Datos Más Implementada Que Nunca Has Implementado

SQLite está instalada en más de un billón de dispositivos. Tu teléfono la tiene. Tu navegador la tiene. Cada instalación de macOS la incluye. Impulsa la base de datos de SMS en Android, el almacenamiento de marcadores en Firefox y los metadatos de fotos en tu iPhone. Y sin embargo, hasta hace poco, la mayoría de los desarrolladores backend la trataban como un juguete — algo para prototipos, aplicaciones móviles y scripts locales, no para ejecutar un servicio web real.

Eso está cambiando rápidamente.

Qué es Realmente SQLite

SQLite no es un servidor de base de datos. No tiene capa de red, ni sistema de autenticación, ni demonio que gestionar. Es una biblioteca C que lee y escribe un único archivo en disco. La enlazas a tu aplicación y la llamas directamente — sin cadenas de conexión, sin números de puerto, sin archivos de configuración que gestionar.

Lo que sí tiene: cumplimiento completo de ACID, una implementación completa de SQL (funciones de ventana, CTEs, soporte JSON, búsqueda de texto completo), rendimiento de consultas en submilisegundos para cargas de trabajo típicas, y un formato de archivo tan estable que el equipo de SQLite garantiza compatibilidad hacia atrás hasta 2050. La base de datos completa es un solo archivo que puedes copiar, enviar por correo electrónico o poner en control de versiones.

Durante 30 años, esa combinación la convirtió en la base de datos dominante para casos de uso integrados — el tipo donde necesitas persistencia sin infraestructura. Pero "integrado" se está redefiniendo.

Por Qué el Uso en Producción No Era Obvio

La crítica tradicional a SQLite para cargas de trabajo de servidor se reduce a dos limitaciones reales:

• Concurrencia: SQLite utiliza bloqueo a nivel de archivo. En modo WAL (WAL = Write-Ahead Log), los lectores no bloquean a los escritores y viceversa, pero aún tienes un escritor a la vez. Las cargas de trabajo de escritura de alta concurrencia se pondrán en cola.
• Máquina única: La base de datos vive en un sistema de archivos. Sin replicación incorporada, sin conmutación por error en espera, sin escrituras multirregión. Si tu servidor muere, también lo hace tu base de datos.

Estas son limitaciones reales. Pero para la mayoría de las aplicaciones web, son irrelevantes. La aplicación CRUD promedio tiene una proporción de lectura/escritura que es 90% lecturas. La concurrencia de escritura más allá de unas pocas docenas de solicitudes por segundo es un problema que la mayoría de las aplicaciones nunca tendrán. La complejidad de Postgres — agrupación de conexiones, retraso de replicación, conmutación por error en espera, migraciones de esquema entre réplicas — existe para resolver problemas que no existen en la escala a la que la mayoría de los desarrolladores realmente operan.

La Ola de SQLite Distribuido

El ecosistema que ha surgido alrededor de SQLite para uso en servidores ha abordado directamente las limitaciones restantes. Tres proyectos están impulsando el cambio.

Turso y LibSQL

LibSQL es un fork de código abierto de SQLite mantenido por Turso. Agrega las características que hicieron que SQLite fuera poco práctico para implementaciones en servidores: replicación en modo WAL sobre HTTP, acceso remoto a través de un protocolo nativo, extensiones cargables habilitadas por defecto y soporte de réplica integrada — lo que significa que tu aplicación puede mantener una copia local de SQLite que se sincroniza desde un primario remoto. Obtienes latencia de lectura local con durabilidad remota.

El resultado es algo que se siente como una base de datos sin servidor pero funciona como un archivo local. El servicio alojado de Turso te permite crear bases de datos en segundos y replicarlas entre regiones sin tocar un archivo de configuración. Su nivel gratuito es tan generoso que las aplicaciones pequeñas nunca pagan un dólar.

Cloudflare D1

Cloudflare D1 ejecuta SQLite dentro de Cloudflare Workers en el borde. Cuando un Worker en Frankfurt consulta D1, está accediendo a una instancia de SQLite que se ejecuta en el mismo centro de datos, no cruzando un océano para llegar a un clúster de Postgres en Virginia. La latencia de consulta que se medía en cientos de milisegundos cae a dígitos individuales.

D1 maneja la replicación de forma transparente. Escribes en un primario, Cloudflare replica las lecturas en ubicaciones periféricas. La API es SQL estándar — puedes usar drizzle-orm, kysely o consultas sin procesar. Es SQLite con una capa de lectura global que no tuviste que construir.

SQLite Integrado de Bun

Bun incluye un enlace nativo de SQLite a partir de v1.1 — sin npm install, sin compilación de módulos nativos, sin dependencia de better-sqlite3 que gestionar. Importas bun:sqlite y abres una base de datos. Eso es todo. Para los desarrolladores de JavaScript que construyen servicios ligeros o herramientas de línea de comandos, la fricción de adoptar SQLite acaba de caer a cero.

Rails 8 lo Hizo el Valor por Defecto

La señal más importante de que SQLite ha cruzado un umbral: Rails 8, lanzado a finales de 2024, incluye SQLite como la base de datos predeterminada para nuevas aplicaciones. Esto no es una conveniencia de prototipo — DHH y el equipo central de Rails han sido explícitos en que SQLite es la opción correcta para la mayoría de las aplicaciones, y han invertido en herramientas para hacerlo listo para producción: solid_queue para trabajos en segundo plano en SQLite, solid_cache para almacenamiento en caché e integración de respaldo basada en Litestream.

Cuando el framework que definió el patrón de aplicación web moderna tiene como valor predeterminado una base de datos basada en archivos, la conversación de la industria ha cambiado.

El Argumento "SQLite para Todo"

El argumento no es sutil: para el 80% de las aplicaciones web, no necesitas Postgres. No necesitas un grupo de conexiones. No necesitas una réplica. Necesitas una base de datos que sea rápida, confiable y que no requiera un administrador de sistemas para operar.

SQLite te da:

• Configuración cero — sin servidor que iniciar, sin usuario que crear, sin puerto que abrir
• Configuración instantánea — crea un archivo, empieza a escribir SQL
• Copias de seguridad triviales — copia el archivo, o usa Litestream para replicación continua a S3
• Excelente rendimiento de lectura — submilisegundo para consultas indexadas en bases de datos de hasta decenas de gigabytes
• Garantías ACID — el modo WAL te da lecturas concurrentes y seguridad contra fallos sin ajustes

La simplicidad operativa se acumula. Cuando tu base de datos es un archivo, tu implementación es más simple. Tu entorno de desarrollo coincide exactamente con producción. La depuración es más fácil. Puedes abrir la base de datos en DB Browser for SQLite y ver los datos directamente.

Donde Todavía No Encaja

SQLite no reemplazará a Postgres en todas partes. Los escenarios de escritura multirregión — donde necesitas escrituras de baja latencia desde múltiples ubicaciones geográficas simultáneamente — son realmente difíciles con SQLite. Puedes solucionarlo con réplicas integradas de LibSQL y enrutamiento cuidadoso de escritura, pero no es nativo. Las cargas de trabajo de escritura de alta concurrencia (piensa: un feed social con millones de escritores simultáneos) encontrarán el cuello de botella de un solo escritor.

El ecosistema de Postgres también es más profundo: mejores extensiones (pgvector, PostGIS, TimescaleDB), herramientas de observabilidad más maduras, décadas de conocimiento operativo y control de concurrencia multiversión que maneja la contención de escritura de manera más elegante. Si estás construyendo un sistema donde el rendimiento de escritura es el cuello de botella, Postgres sigue siendo la opción correcta.

El Cambio es Real

El patrón aquí no es nuevo. SQLite pasó de ser un "juguete" a una "opción seria" al resolver los problemas que lo mantenían en el mundo integrado — y lo hizo no volviéndose más complejo, sino inspirando un ecosistema que agregó las piezas faltantes a su alrededor. LibSQL agregó replicación. D1 agregó la capa de borde. Litestream agregó copia de seguridad continua. Bun eliminó la fricción de instalación.

El resultado es un motor de base de datos que ha sido probado en producción en un billón de dispositivos, no requiere infraestructura para ejecutarse y ahora tiene respuestas creíbles para las dos objeciones que solían descalificarlo. La pregunta no es si SQLite puede manejar tu aplicación — es si tu aplicación realmente necesita lo que Postgres proporciona.

Para la mayoría de las aplicaciones, la respuesta honesta es no.