Cuándo usar SQLite: casos de uso, límites y alternativas

La pregunta clave

SQLite no es una versión reducida de Postgres. Es una herramienta con otra forma. La base de datos entera es un archivo en disco, y tu aplicación habla con ella a través de una librería enlazada al mismo proceso: nada de servidor, ni red, ni usuarios. Ese diseño hace que SQLite sea brillante para ciertos trabajos y una mala elección para otros.

La pregunta que decide casi nunca es "¿es SQLite lo bastante rápido?" (normalmente lo es). Es "¿la forma de mi aplicación encaja con aquello en lo que SQLite es bueno?". Dos cosas lo determinan en gran medida: dónde vive el dato y cuántas cosas escriben en él a la vez.

Cuándo usar SQLite: cuando los datos viven con la app

SQLite brilla cuando la base de datos pertenece a una sola aplicación en una sola máquina. El archivo está junto a tu código, tu app lo abre directamente, y esa es toda la arquitectura.

-- Un esquema típico de "los datos viven con la aplicación":
-- el almacenamiento local de una app de notas de escritorio.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Compras', 'leche, pan, café'),
    ('Ideas',   'esquema del tutorial de sqlite');

SELECT id, title, created FROM notes;

Ese pequeño esquema podría ser el backend completo de una app real. Algunos casos donde este patrón encaja de forma natural:

• Apps de escritorio y móviles. Cada app de iOS y Android que necesita almacenamiento local estructurado usa SQLite por debajo. Lo mismo hacen Firefox, Chrome y la mayoría de los navegadores.
• Herramientas CLI. git, los gestores de paquetes y los gestores de dotfiles usan bases de datos embebidas.
• Dispositivos embebidos. Routers, coches, aviones — cualquier cosa que necesite una base de datos en unos pocos cientos de kilobytes.
• Suites de tests. Un archivo SQLite recién creado (o una base de datos :memory:) por test es más rápido y está más aislado que levantar un Postgres.

Si tus datos no necesitan compartirse entre varias máquinas, lo más probable es que SQLite sea la respuesta correcta.

SQLite para aplicaciones web con muchas lecturas

SQLite maneja las lecturas de maravilla. Muchos lectores concurrentes, sin contención y consultas en microsegundos para búsquedas indexadas. Si tu sitio se trata sobre todo de gente leyendo contenido — blogs, documentación, sitios de marketing, dashboards pequeños de SaaS — SQLite aguantará perfectamente, y muchas veces mejor que un Postgres por red, porque no hay ida y vuelta de por medio.

-- Tabla de publicaciones de un blog.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hola-mundo', 'Hola, Mundo', 'Primera publicación.', '2024-01-01'),
    ('sqlite-mola', 'Por qué SQLite',  'Base de datos en un solo archivo.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

La pega son las escrituras. SQLite serializa las escrituras: solo un escritor puede tener el bloqueo a la vez. Para un blog con un par de autores, ni te enteras. Para una app de chat con miles de usuarios publicando mensajes cada segundo, ya es harina de otro costal.

El modo WAL (write-ahead logging, lo veremos más adelante) sube bastante ese techo, ya que permite que los lectores y el escritor trabajen en paralelo. Hay un montón de sitios en producción sirviendo millones de peticiones al día con SQLite + WAL.

SQLite para cachés locales y datos temporales

Siempre que necesites almacenamiento local estructurado — algo más que un JSON suelto pero menos que un servidor de base de datos completo —, SQLite es difícil de superar.

-- Una tabla de caché para un cliente HTTP.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Logs, buffers de analítica, staging de ETL, feature stores de machine learning, índices de IDEs… todos son escenarios donde SQLite encaja como anillo al dedo. El archivo es portable, el lenguaje de consulta es SQL completo y no hay ningún servidor del que estar pendiente.

Cuándo no usar SQLite: muchos escritores concurrentes

Esta es la limitación que pilla a más de uno por sorpresa. SQLite usa un bloqueo de escritura a nivel de base de datos: un solo escritor, sin matices. Si dos procesos intentan insertar en el mismo instante, uno espera.

Para la mayoría de aplicaciones eso da igual: las escrituras son escasas y rápidas. Pero si tu carga de trabajo se parece a esto:

• Un SaaS multi-tenant con miles de usuarios escribiendo a la vez,
• Una cola de mensajes o un log de eventos de alto throughput,
• El backend de un juego en tiempo real o un chat con cambios de estado constantes,

entonces SQLite se va a convertir en el cuello de botella. PostgreSQL y MySQL usan bloqueo a nivel de fila y están pensados precisamente para esos casos. Tira de ellos.

-- El error que verás cuando se acumulen los escritores:
Error: database is locked

If you're seeing that under normal load, SQLite is the wrong tool — not a bug to work around.

No uses SQLite entre varias máquinas

SQLite es una biblioteca que corre dentro del propio proceso. La aplicación lee y escribe el archivo directamente, así que ese archivo tiene que estar en un disco al que la aplicación pueda hacerle read() y write() con llamadas normales del sistema de archivos.

Eso descarta lo siguiente:

• Varios servidores de aplicación detrás de un balanceador de carga que quieran compartir una misma base de datos. (Sistemas de archivos en red como NFS técnicamente funcionan, pero corrompen el archivo bajo carga. No lo hagas.)
• Funciones serverless, donde cada invocación se ejecuta en una máquina distinta.
• Pods de Kubernetes que necesiten una base de datos compartida — salvo que uses un despliegue de un único pod con un volumen persistente.

Si tu arquitectura tiene más de un proceso en más de una máquina escribiendo en la base de datos, necesitas una base de datos cliente-servidor. Ahí está el límite.

No uses SQLite si necesitas usuarios a nivel de base de datos

SQLite no tiene ningún concepto de usuarios, roles ni permisos. La base de datos es un archivo: quien pueda leer el archivo lo lee todo, y quien pueda escribirlo lo escribe todo. El control de acceso es tarea del sistema operativo.

Para una app de escritorio de un solo usuario, eso está bien. Pero para un sistema multitenant donde distintas personas necesitan distintos privilegios dentro de la base de datos, lo que quieres es Postgres o MySQL.

Checklist rápido para decidir

Repasa esta lista. Si respondes "sí" a todo, SQLite probablemente sea una opción excelente:

• La base de datos vive en la misma máquina que la aplicación.
• Hay un proceso (o unos pocos, mayormente de lectura) que se comunica con ella.
• Los datos totales caben sin problema en un disco — terabytes están bien, pero sigue siendo un único disco.
• No necesitas permisos de usuario a nivel de base de datos.
• Las escrituras concurrentes son ocasionales, no el grueso del trabajo.

Si alguna respuesta es "no", mira mejor Postgres o MySQL. Las dos páginas siguientes los comparan de frente.

Lo que te llevas

• SQLite es la elección correcta cuando la base de datos es local a la aplicación: escritorio, móvil, embebido, herramientas de línea de comandos, suites de tests, sitios con muchas lecturas, cachés locales.
• Es apto para producción — viene en miles de millones de dispositivos. Las restricciones son arquitectónicas, no de calidad.
• Sáltatelo cuando necesites muchos escritores concurrentes, acceso desde varias máquinas o permisos por usuario en la base de datos.

Siguiente: instalar SQLite

Basta de teoría. La siguiente página te guía para tener SQLite en tu máquina — ya viene incluido en macOS y en la mayoría de distros de Linux, y en Windows es una sola descarga — y verificar la instalación desde la línea de comandos.