Bases de datos: Parte 4 — SQLite

SQLite — una base de datos relacional embebida. A diferencia de MySQL y PostgreSQL, no tiene un proceso servidor separado: es una biblioteca en C que se enlaza con la aplicación, y toda la base se almacena en un único archivo en disco. La aplicación lee y escribe ese archivo directamente, sin red y sin intermediarios.

El código fuente de SQLite está en el dominio público (dominio público), por lo que se puede usar en cualquier proyecto, incluidos los comerciales, sin restricciones de licencia.

Qué puede hacer SQLite

A pesar de su compacidad, SQLite soporta gran parte del SQL estándar:

• transacciones con propiedades ACID — los cambios o se guardan por completo, o no se guardan en absoluto, incluso ante un corte de energía;
• índices, vistas, triggers, claves foráneas;
• funciones de ventana, expresiones de tabla común (WITH), incluyendo recursivas;
• trabajo con JSON mediante funciones integradas;
• búsqueda de texto completo mediante la extensión FTS5.

El tamaño máximo de la base es de alrededor de 281 TB; en la práctica, la limitación la impone el sistema de archivos.

Dónde se usa SQLite

Aplicaciones móviles y de escritorio. SQLite está integrada en Android e iOS y sirve como la forma estándar de almacenar datos de la aplicación en el dispositivo. Firefox y Chrome la usan para historial, marcadores y ajustes; Adobe Lightroom Classic — para el catálogo de fotos. No hay que instalar un servidor; los datos están disponibles sin internet.

Sitios y pequeños servicios web. Los desarrolladores de SQLite consideran que es adecuada para sitios con hasta 100 000 solicitudes al día, y con una configuración cuidadosa incluso varias veces más. El sitio sqlite.org funciona él mismo sobre SQLite y atiende 400–500 mil solicitudes HTTP por día en una máquina virtual. La condición es una: en el sitio predomina la lectura y las escrituras son moderadas.

Sistemas embebidos e IoT. La biblioteca ocupa unos pocos cientos de kilobytes y casi no necesita memoria, por lo que se usa en routers, electrónica a bordo y controladores industriales.

Formato de archivo. El archivo SQLite es conveniente como formato de documento o de archivo: se puede transferir, copiar y a la vez hacer consultas SQL sobre él.

Desarrollo y tests. Django crea por defecto un proyecto con base SQLite. Para un prototipo y pruebas automáticas no hace falta levantar un servidor separado.

Cómo SQLite maneja la escritura

La limitación principal de SQLite es que en cada momento solo una conexión puede escribir en la base. Las demás esperan hasta que la escritura termine. Dependiendo del modo de journal, la escritura puede o no interferir con la lectura.

Modo por defecto (rollback journal). Durante una escritura la base se bloquea y los lectores esperan a que termine la transacción. Para una aplicación de escritorio con un solo usuario esto no se nota; para un sitio puede convertirse en un cuello de botella.

Modo WAL (Write-Ahead Logging). Los cambios se escriben primero en un archivo de journal separado y se trasladan al archivo principal de la base más tarde, durante un checkpoint. Los lectores no bloquean al escritor, y el escritor no bloquea a los lectores. Se activa con un solo comando, y el modo se conserva en el archivo de la base:

PRAGMA journal_mode=WAL;

Para un servidor que accede a SQLite desde varios hilos o procesos, normalmente se añaden dos ajustes más por conexión:

PRAGMA busy_timeout = 5000;   -- esperar hasta 5 segundos si la base está ocupada, en lugar de un error inmediato
PRAGMA synchronous = NORMAL;  -- en modo WAL la base no se corrompe ante una caída, pero las últimas transacciones pueden perderse

El modo WAL tiene limitaciones que conviene conocer de antemano:

• el escritor sigue siendo uno — WAL acelera la lectura, pero no hace las escrituras paralelas;
• todos los procesos que usan la base deben estar en el mismo equipo: WAL usa memoria compartida, por lo que no funciona sobre sistemas de archivos en red (NFS, SMB);
• junto a la base aparecen archivos auxiliares -wal y -shm, que no se deben eliminar y no se puede copiar la base sin tenerlos en cuenta;
• transacciones mayores de 100 MB en modo WAL funcionan lentamente.

Mantenimiento de la base

Para trabajar con la base manualmente hay una utilidad de consola sqlite3:

sqlite3 /var/lib/app/app.db

.tables                 -- lista de tablas
.schema orders          -- estructura de la tabla
.mode box               -- salida tabular conveniente de resultados
EXPLAIN QUERY PLAN SELECT * FROM orders WHERE customer_id = 42;  -- si la consulta usa un índice

Conviene ejecutar periódicamente varias operaciones:

• PRAGMA optimize; — actualiza las estadísticas que SQLite usa para elegir índices. La documentación recomienda ejecutarlo antes de cerrar una conexión de larga duración o cada pocas horas;
• VACUUM; — recompone el archivo y libera espacio tras borrados masivos. Durante su ejecución la base se bloquea, y en disco se necesita espacio libre del tamaño de la base;
• PRAGMA integrity_check; — comprueba la integridad del archivo.

Copias de seguridad

Copiar simplemente el archivo de una base en uso no es seguro: si en el momento de copiar hay una escritura, la copia puede quedar inconsistente, y en modo WAL parte de los datos puede estar todavía en el archivo de journal. Hay tres maneras fiables.

Comando .backup en la utilidad sqlite3. Usa el mecanismo de copia de seguridad integrado y hace una copia consistente de la base en uso:

sqlite3 /var/lib/app/app.db ".backup '/backup/app-$(date +%F).db'"

VACUUM INTO. Crea una nueva copia comprimida de la base sin alterar la original (disponible desde la versión 3.27.0):

VACUUM INTO '/backup/app-2026-09-21.db';

Litestream. Programa independiente de código abierto que transmite de forma continua los cambios del journal WAL a un almacenamiento de objetos S3 o a un directorio local. No hace falta cambiar la aplicación: Litestream funciona como un proceso separado. Esto permite restaurar la base hasta unos segundos antes del fallo, y no solo hasta la última copia nocturna.

Sea como sea que se haga la copia, debe comprobarse regularmente restaurándola: sqlite3 копия.db "PRAGMA integrity_check;" debe devolver ok.

Ventajas

• Sin servidor. No hay que instalar, configurar, actualizar ni proteger un servicio separado; no hay latencia de red.
• Despliegue sencillo. La base es un único archivo que se mueve junto con la aplicación.
• Fiabilidad. Transacciones ACID y exhaustivas pruebas: SQLite es uno de los programas más probados del mundo.
• Funciona sin red. La aplicación es completamente funcional offline.
• Velocidad en lecturas. Para volúmenes pequeños y medianos de datos, las consultas a un archivo local son más rápidas que a un servidor por la red.
• Sin restricciones de licencia. Dominio público.

Desventajas

• Un solo escritor. Con escrituras concurrentes frecuentes, SQLite queda por detrás de SGBD cliente-servidor incluso en modo WAL.
• Sin acceso en red. Si varios servidores de aplicaciones deben trabajar con la misma base, SQLite no es adecuada: no se debe poner su archivo en un disco de red compartido.
• Sin usuarios ni controles de permisos. El acceso a los datos se determina por los permisos del archivo en el sistema operativo.
• Tipado laxo. Por defecto una columna puede almacenar valores de cualquier tipo. Desde la versión 3.37.0 se puede activar en la tabla el modo estricto (CREATE TABLE ... STRICT), donde los tipos se verifican.
• Sin escalado horizontal. Todos los datos están en un solo disco de un solo equipo.

Cuándo elegir SQLite y cuándo no

SQLite es apropiada si:

• los datos se usan en el mismo dispositivo o servidor donde corre la aplicación;
• las consultas de lectura son mucho más numerosas que las de escritura;
• el volumen de datos se mide en gigabytes, no en terabytes;
• importa la simplicidad: un proceso, un archivo, mínimo mantenimiento.

Se necesita un SGBD cliente-servidor (PostgreSQL, MySQL) si:

• varios servidores de aplicaciones acceden a la base o está en una máquina separada;
• las escrituras son constantes y desde muchas fuentes simultáneamente — por ejemplo, en procesamiento intenso de pedidos;
• se requieren usuarios con distintos permisos, replicación y tolerancia a fallos a nivel de base.

Un error común es empezar un proyecto con SQLite, ejecutar una segunda instancia de la aplicación en otro servidor y poner el archivo de la base en un disco de red compartido. Ese esquema lleva a bloqueos y corrupción de datos; en ese momento es hora de cambiar a un SGBD servidor.

SQLite funciona bien donde sus limitaciones no importan: en aplicaciones móviles y de escritorio, dispositivos embebidos, sitios pequeños y servicios internos con escritura moderada. En esas condiciones sale más barato y sencillo que cualquier base de datos servidor.