SQLite es la base de datos más desplegada del mundo — y casi nadie habla de ella

Las bases de datos que reciben atención son las que operas: clústeres de PostgreSQL, réplicas de MySQL, shards de MongoDB, servicios gestionados en la nube de AWS y Google. La base de datos que está en más lugares que todas ellas juntas se ejecuta silenciosamente en segundo plano, no requiere administrador, consume menos de 1 MB de espacio en disco para su biblioteca, y es un único archivo fuente C que cualquier desarrollador puede leer en una tarde.
SQLite está en todas partes. Es el motor de almacenamiento dentro de cada aplicación iOS y Android que necesita datos estructurados. Está incrustada en cada navegador de escritorio — Chrome, Firefox, Safari y Edge usan SQLite para el historial, marcadores y datos en caché. Es la base de datos que impulsa el software de gestión de vuelos en aviones Airbus y Boeing. Está dentro de televisores, autos, routers y dispositivos médicos. El proyecto SQLite estima más de un billón de despliegues en uso activo — un número tan grande que es difícil de verificar, pero también difícil de disputar dado cuántas pilas de software sustenta.
El diseño que lo hace diferente
Cualquier otra base de datos SQL que hayas usado probablemente es un sistema cliente-servidor: la base de datos se ejecuta como un proceso separado, te conectas a través de un socket (local o de red), envías consultas y recibes resultados. SQLite no tiene servidor — todo el motor de base de datos es una biblioteca que se ejecuta dentro del proceso de tu aplicación. No hay servidor que iniciar, ningún archivo de configuración que gestionar, ningún sistema de permisos de usuario, ningún puerto de red que abrir. Enlazas contra la biblioteca y tienes una base de datos SQL completa.
La base de datos en sí es un solo archivo en el sistema de archivos. Esto es tanto su mayor fortaleza como su limitación clave. Mover una base de datos SQLite es una copia de archivo. Hacer una copia de seguridad es una copia de archivo. Inspeccionarla no requiere herramientas especiales — SQLite Browser o la CLI de sqlite3 abrirán cualquier archivo de base de datos en cualquier sistema operativo. Cuando tu aplicación termina, no hay nada que apagar.
La limitación es la concurrencia: SQLite usa bloqueo a nivel de archivo, lo que significa que solo un escritor puede modificar la base de datos a la vez. Múltiples lectores concurrentes están bien; múltiples escritores concurrentes se serializan. Para aplicaciones con alta concurrencia de escritura — servidores web de alto tráfico que manejan solicitudes simultáneas — esta restricción importa. Para la gran mayoría de aplicaciones, incluyendo la mayoría de aplicaciones móviles, herramientas de escritorio y servicios web de tráfico moderado, no importa.
Por qué SQLite es lo suficientemente confiable para volar
El código base de SQLite es una de las piezas de software más exhaustivamente probadas que existen. El proyecto mantiene aproximadamente 600 veces más código de prueba que código de producción — la biblioteca en sí tiene alrededor de 150,000 líneas de C; el conjunto de pruebas tiene alrededor de 90 millones de líneas, incluyendo un fuzzer SQL completo, TH3 (un arnés de prueba comercial para pruebas rigurosas contra casos extremos), y pruebas exhaustivas de recuperación de corrupción.
El estándar de confiabilidad es inusual para software de código abierto. D. Richard Hipp, el creador de SQLite, lo ha diseñado explícitamente para ser adecuado para sistemas críticos de seguridad aeronáutica, y Airbus y otros lo han certificado en consecuencia. La base de datos proporciona garantías ACID — Atomicidad, Consistencia, Aislamiento, Durabilidad — a través de un sistema de registro de escritura anticipada (WAL). Un bloqueo en medio de una transacción deja la base de datos en un estado conocido y bueno; el WAL asegura que se confirme la transacción completa o ninguna, incluso ante una pérdida inesperada de energía.
El sorprendente piso de rendimiento
La arquitectura sin servidor de SQLite significa que evita la sobrecarga que incurren las bases de datos cliente-servidor: sin serialización de datos para enviar a través de un socket, sin cambios de contexto entre procesos de cliente y servidor, sin planificación de consultas a través de un límite de red. Para cargas de trabajo donde las consultas son simples y la base de datos es de tamaño pequeño a mediano, el rendimiento de SQLite a menudo es comparable con PostgreSQL y a veces más rápido.
El equipo de SQLite realizó benchmarks en 2022 que mostraron que para una carga de trabajo con muchas lecturas (35 lecturas por cada escritura), SQLite en un SSD NVMe común procesó 48,000 transacciones por segundo en comparación con las 7,000 de PostgreSQL — en gran parte porque la arquitectura intraproceso de SQLite elimina la sobrecarga de comunicación entre procesos. Para cargas de trabajo con muchas escrituras, la imagen es más matizada; el manejo concurrente de escritura de PostgreSQL le da ventajas en escenarios de alta contención.
La implicación práctica: muchas aplicaciones que recurren a PostgreSQL porque es "de grado de producción" funcionarían bien y serían operativamente más simples con SQLite. El servicio D1 distribuido de SQLite de Cloudflare y Turso's libSQL (un fork de SQLite con soporte de replicación) están construyendo infraestructura alrededor de la apuesta de que la simplicidad de SQLite ha sido subvalorada en aplicaciones del lado del servidor.
SQLite moderno: no es la versión de 2005
SQLite ha evolucionado significativamente. El soporte JSON agregado en 2015 y extendido hasta 2022 permite consultar e indexar datos JSON anidados con semántica SQL completa — competitivo con bases de datos documentales para muchos casos de uso. La extensión Full-Text Search 5 (FTS5) proporciona búsqueda de texto completo clasificada por BM25 con consultas de prefijo, sin requerir un índice de búsqueda separado. La extensión R*Tree maneja consultas de rango geoespacial. Las tablas virtuales permiten a SQLite consultar fuentes de datos externas (archivos CSV, API remotas) con sintaxis SQL.
La adición más reciente es la extensión de búsqueda de similitud vectorial — sqlite-vss, construida sobre la biblioteca FAISS de Facebook — que agrega búsqueda aproximada del vecino más cercano a SQLite. Esto significa que un solo archivo SQLite puede almacenar documentos, sus embeddings vectoriales, y realizar búsqueda de similitud semántica, convirtiéndolo en una base de datos RAG (generación aumentada por recuperación) incrustada viable para aplicaciones locales de IA. La combinación de consultas estructuradas, búsqueda de texto completo y búsqueda vectorial en una sola base de datos sin configuración es convincente para aplicaciones que antes requerían tres sistemas separados.
Cuándo no usar SQLite
La respuesta honesta a "¿debería usar SQLite?" requiere reconocer sus limitaciones reales. Cargas de trabajo de escritura de alta concurrencia — piensa en una aplicación web manejando miles de transacciones simultáneas — necesitan la concurrencia de múltiples escritores que proporciona PostgreSQL. Conjuntos de datos sustancialmente más grandes que la RAM disponible se benefician del grupo de búfer y el planificador de consultas de PostgreSQL, que está optimizado para escenarios de datos grandes. Las aplicaciones que requieren control de acceso detallado (seguridad a nivel de fila, permisos a nivel de columna) necesitan una base de datos basada en servidor.
Pero estas son limitaciones que afectan a una minoría de despliegues. La aplicación web CRUD típica, la aplicación móvil, la herramienta de escritorio, el sistema embebido y el script de pipeline de datos se benefician bien de la simplicidad de SQLite. El consejo de que SQLite "no escala" o "no está listo para producción" está obsoleto desde hace una década — escala verticalmente a tamaños muy grandes y ha estado alimentando aplicaciones de producción de manera confiable desde principios de los 2000. La brecha entre las capacidades reales de SQLite y su reputación entre los desarrolladores que no lo han usado recientemente es sustancial, y vale la pena corregirla.