Qué es SQLite: la base de datos SQL embebida

SQLite es una base de datos dentro de tu programa

La mayoría de las bases de datos que conoces — MySQL, Postgres, SQL Server — corren como un programa aparte. Levantas un servidor, este escucha en un puerto y tu aplicación se conecta por red para hacerle consultas. SQLite tira ese modelo por la ventana.

SQLite es una biblioteca. La enlazas dentro de tu programa y te entrega una base de datos SQL que vive en un único archivo en disco. No hay servidor, ni puerto, ni demonio, ni pg_ctl start. Tu aplicación abre un archivo, y ese archivo es la base de datos.

sqlite3 mydata.db

Ese comando abre (o crea) un archivo llamado mydata.db y te deja en un prompt de SQL. Todo lo que hagas —tablas, filas, índices— se guarda en ese único archivo. Cópialo a otra máquina y te llevas la base de datos contigo. Bórralo y la base de datos desaparece.

Un vistazo rápido al SQL

El SQL en sí se ve igual que en cualquier otro motor. Si ya has trabajado con otra base de datos, casi todo te va a resultar familiar:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

SQL estándar de toda la vida — CREATE TABLE, INSERT, SELECT, ORDER BY. SQLite soporta las partes del estándar SQL que realmente usas en el día a día, además de cosas más modernas como CTEs, funciones de ventana y funciones JSON. Las diferencias con Postgres o MySQL están sobre todo en los tipos y en alguna que otra peculiaridad de sintaxis, pero eso lo veremos más adelante.

Qué significan "embebida" y "sin servidor" en la práctica

Hay dos palabras que aparecen una y otra vez al hablar de SQLite. Conviene tenerlas claras desde el principio.

Embebida quiere decir que SQLite corre dentro del mismo proceso que tu aplicación. No hay un proceso de base de datos aparte. Cuando tu script de Python llama a sqlite3.connect("data.db"), el motor SQL se ejecuta dentro de tu propio proceso de Python y lee y escribe el archivo directamente.

Sin servidor significa que no hay ningún servidor que instalar, configurar, levantar, asegurar ni respaldar. Compara los pasos necesarios para empezar a usar una base de datos:

• Postgres: instalar Postgres, arrancar el servicio, crear un usuario, crear una base de datos, configurar pg_hba.conf y conectar por TCP.
• SQLite: abrir un archivo.

Esa es toda la diferencia. Menos potencia, pero muchísimo menos lío.

Toda la base de datos cabe en un único archivo

Esta es la parte que sorprende a mucha gente. El formato del archivo está documentado y es estable — un fichero .db (o .sqlite, o .sqlite3; la extensión es pura convención) que puedes:

• Enviarle por correo a un compañero.
• Subir a git (los pequeños, claro).
• Copiar con cp para tener un backup al instante.
• Abrir con cualquier herramienta de SQLite, en cualquier sistema operativo.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

Ese único archivo guarda tus tablas, tus índices, tu esquema y tus datos. Las bases de datos SQLite en disco son idénticas byte a byte en Windows, macOS, Linux, iOS y Android. El formato es tan estable que la Biblioteca del Congreso de Estados Unidos lo recomienda para la preservación de datos a largo plazo.

Dónde ya estás usando SQLite

Es casi seguro que tienes cientos de bases de datos SQLite en el dispositivo desde el que lees esto. SQLite mueve por dentro:

• El almacenamiento del sistema en iOS y Android, además de muchísimas apps en ambas plataformas.
• Firefox, Chrome y Safari (historial, marcadores, cookies).
• macOS (Mail, Fotos, el dock).
• La mayoría de aplicaciones de escritorio en Linux que necesitan almacenamiento local.
• Skype, WhatsApp, Signal — el historial de chats.
• Los catálogos de Adobe Lightroom, los metadatos de Dropbox, las bibliotecas de Steam.

Se le considera el motor de base de datos más desplegado del mundo, y probablemente sea cierto. La razón es sencilla: cuando una aplicación necesita almacenamiento local estructurado, SQLite es el camino con menos fricción.

Lo que SQLite no es

No es una base de datos cliente-servidor. Dos programas en máquinas distintas no pueden conectarse a la vez a una base de datos SQLite por red — no hay capa de red a la que conectarse. Si necesitas eso, lo tuyo es Postgres o MySQL.

Tampoco está pensada para concurrencia alta de escritura. SQLite usa bloqueo a nivel de archivo (con algunas optimizaciones bastante ingeniosas en modo WAL), así que aunque muchos lectores pueden trabajar en paralelo, solo un escritor a la vez puede hacer commit. Para una app de un solo usuario o un sitio web de poco tráfico, esto no es problema. Para un SaaS multi-tenant recibiendo miles de escrituras por segundo, es la herramienta equivocada.

No gestiona usuarios ni permisos. El acceso a la base de datos es acceso al archivo: quien pueda leer el archivo puede leer los datos. Eso está bien para una app que es dueña de su propio archivo. No está bien para un entorno multi-tenant compartido.

Por qué elegirla

El trato es cambiar simplicidad por un margen de escalado que probablemente nunca necesites:

• Cero configuración. Sin servicio que levantar. Sin desajustes de versión entre desarrollo y producción. Sin "se cayó la base de datos" porque no hay servidor de base de datos.
• Rápida. En la mayoría de cargas de trabajo, sobre todo las que leen mucho, SQLite es más rápida que una base de datos en red — no hay ida y vuelta por socket en cada consulta.
• Fiable. Se prueba de forma obsesiva. El proyecto SQLite tiene mucho más código de tests que de código fuente, con bastante diferencia, y el formato es estable desde 2004.
• Dominio público. Libre para cualquier uso, incluido el comercial. Ni siquiera hay licencia que leer.
• Portátil. Un archivo, todas las plataformas.

Para apps locales, prototipos, dispositivos embebidos, herramientas de línea de comandos, suites de tests, scripts de análisis de datos y sitios web pequeños o medianos, SQLite suele ser la opción correcta por defecto — no un escalón hacia una base de datos "de verdad".

Lo siguiente: SQLite vs MySQL

Una pregunta que sale sola es cómo se compara SQLite con los servidores de bases de datos de los que probablemente has oído hablar más. Vamos a empezar por MySQL: dónde gana cada uno y cómo saber cuál encaja con el proyecto que tienes entre manos.