SQLite o un servidor de base de datos: cuándo cambiar

SQLite es una base de datos que vive en un único archivo y corre dentro de tu aplicación. PostgreSQL y MySQL son servidores de base de datos: procesos separados con los que tu aplicación habla a través de una conexión de red. Los dos hablan SQL, pero resuelven problemas distintos, y elegir mal se paga más tarde: escrituras lentas, archivos bloqueados o una migración dolorosa.

La comparación de abajo parte del caso más común: un bot, una API o un sitio web que empezó pequeño y puede crecer. Si todavía estás eligiendo el tipo de base de datos, lee primero cómo elegir una base de datos para tu proyecto.

¿Qué diferencia hay entre SQLite y un servidor de base de datos?#

SQLite es una biblioteca. Tu aplicación abre un archivo, como app.db, y lee y escribe en él directamente. No hay nada que instalar, ni puerto, ni contraseña, ni proceso aparte. Por eso viene dentro de teléfonos, navegadores y muchas aplicaciones de escritorio.

Un servidor de base de datos (PostgreSQL, MySQL) es un proceso de larga duración que es dueño de los archivos de datos. Tu aplicación se conecta por TCP, se autentica y envía consultas. El servidor coordina a todos los clientes, así que muchas aplicaciones y máquinas pueden compartir una base de datos con seguridad. Consulta qué es PostgreSQL y qué es MySQL.

¿Cómo maneja SQLite las escrituras simultáneas?#

SQLite deja que muchas conexiones lean a la vez, pero solo una puede escribir por vez. En el modo por defecto (rollback journal), un escritor también puede bloquear a los lectores mientras confirma. Cambiar al modo WAL (write-ahead log) permite que lectores y un escritor trabajen al mismo tiempo, aunque sigue habiendo un solo escritor.

Basta con activarlo una vez por base de datos, porque el ajuste se guarda en el archivo y se mantiene entre conexiones:

import sqlite3

con = sqlite3.connect("app.db", timeout=10)  # un escritor bloqueado espera hasta 10 s
print(con.execute("PRAGMA journal_mode=WAL").fetchone())  # ('wal',)
con.execute("PRAGMA foreign_keys=ON")  # desactivado por defecto, actívalo en cada conexión
con.execute("CREATE TABLE IF NOT EXISTS orders (id INTEGER PRIMARY KEY, total REAL NOT NULL)")
with con:
    con.execute("INSERT INTO orders (total) VALUES (?)", (19.9,))
print(con.execute("SELECT COUNT(*) FROM orders").fetchone())
con.close()

Si el pragma no puede cambiar de modo, devuelve el modo anterior, así que revisa el valor impreso. Incluso en modo WAL, una consulta puede devolver SQLITE_BUSY en casos raros: maneja ese error en el código que escribe a menudo.

Para un bot que guarda ajustes unas cuantas veces por minuto, un solo escritor por vez pasa desapercibido. Para una API que recibe cientos de escrituras por segundo, cada escritura hace cola detrás de la anterior.

¿Cómo maneja la concurrencia un servidor de base de datos?#

PostgreSQL usa control de concurrencia multiversión (MVCC). Cada consulta ve una foto consistente de los datos, así que leer nunca bloquea escribir y escribir nunca bloquea leer. Los escritores solo se esperan entre sí cuando tocan la misma fila. Dos peticiones que actualizan filas distintas corren en paralelo.

Ese bloqueo por fila es lo principal que ganas al pasar a un servidor. También es la razón de que un servidor requiera más cuidado: el límite de conexiones, el tamaño del pool y las credenciales pasan a ser tu problema. Si chocas con ellos, consulta el error too many connections.

¿Varios servidores pueden compartir un archivo SQLite?#

No de forma segura. La documentación de SQLite explica que sus bloqueos de escritura fallan en algunos sistemas de archivos de red, lo que puede corromper la base de datos. El modo WAL ni siquiera funciona sobre un sistema de archivos de red, porque todos los procesos deben estar en la misma máquina.

Este es el motivo más común para cambiar. En cuanto ejecutas una segunda instancia de tu aplicación, para balanceo de carga o como worker separado en otra máquina, cada instancia necesita llegar a los mismos datos por la red. Para eso existe un servidor de base de datos.

¿Qué tamaño puede alcanzar SQLite?#

Más del que la mayoría de los proyectos va a necesitar. El máximo teórico es de unos 281 TB con el tamaño de página más grande, y de unos 17,5 TB con la página por defecto de 4096 bytes. Un único string o blob tiene un límite de 1.000.000.000 bytes por defecto.

El tamaño rara vez es el motivo para dejar SQLite. El equipo de SQLite sugiere un motor cliente/servidor cuando los datos pueden acercarse a la escala de terabytes, sobre todo porque un único archivo es difícil de distribuir, copiar y ajustar a ese tamaño.

¿Cuándo deberías pasar de SQLite a un servidor de base de datos?#

Cambia cuando se cumpla una o más de estas condiciones:

1. Más de una máquina necesita los datos. Una segunda instancia de la aplicación, un worker separado o un esquema con balanceo de carga.
2. Los escritores chocan. Los logs muestran database is locked o las escrituras tardan más a medida que crece el tráfico, incluso con WAL y un timeout.
3. Necesitas roles y permisos. Distintos servicios o personas deben ver tablas distintas.
4. Quieres funciones de servidor. Extensiones, replicación, tipos de índice avanzados o tipos de datos especializados.
5. Los datos crecen hacia los terabytes.

Quédate con SQLite cuando un proceso es dueño de los datos, las escrituras son moderadas y valoras no tener que configurar nada. Eso cubre muchos bots, herramientas internas, prototipos y sitios de tráfico bajo o medio. Si solo necesitas datos temporales rápidos, Redis puede encajar mejor que ambos.

¿Cómo se pasa de SQLite a PostgreSQL?#

1. Aísla tus consultas. Pon el SQL detrás de una pequeña capa de datos o de un ORM, para que solo cambie esa capa.
2. Corrige los tipos. SQLite acepta casi cualquier valor en cualquier columna, salvo que la tabla sea STRICT. PostgreSQL rechaza los datos incorrectos, así que revisa antes fechas, booleanos y números.
3. Reescribe las diferencias de SQL. Los placeholders (? pasa a $1 en muchos drivers), AUTOINCREMENT pasa a GENERATED ... AS IDENTITY, y algunas funciones cambian.
4. Crea el esquema con migraciones. Consulta migraciones de base de datos en el deploy.
5. Copia los datos, compara el número de filas y después apunta la aplicación a la base nueva.
6. Conserva el archivo antiguo hasta haber verificado la base nueva y tener una copia de seguridad.

Elige el servidor según la forma de los datos. Para datos relacionales, PostgreSQL vs MySQL repasa las ventajas y desventajas.

Cómo hacerlo en Square Cloud#

SQLite no necesita hosting de base de datos: es un archivo que tu aplicación abre por sí misma. El disco de una aplicación persiste entre reinicios y deploys, así que el archivo sobrevive. Un deploy (un ZIP nuevo o un push) sobrescribe solo los archivos que subes, así que deja el archivo .db fuera, o reemplazará tus datos en producción. Cada aplicación tiene su propio disco, y las aplicaciones detrás de un balanceador de carga no comparten archivos. Por eso SQLite sigue siendo una opción de instancia única.

Cuando se te quede corto, Square Cloud ofrece hosting de PostgreSQL, MySQL, MongoDB y Redis a partir del plan Standard. Creas la base de datos en el panel y se aprovisiona en segundos en el mismo datacenter que tus aplicaciones, con alrededor de 1 ms de latencia media y TLS obligatorio. El panel te da la URL de conexión completa y un certificado para descargar. Copia la URL en las variables de entorno de tu aplicación y ejecuta tú mismo la migración.

Puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos tiene también un snapshot automático diario. Puedes restaurar un snapshot en la misma base, en otra del mismo motor o en una base nueva. Compara las opciones en la página de bases de datos.