Cuándo usar una base de datos y cuándo basta un JSON

El JSON no es una base de datos, pero a veces es suficiente

La decisión técnica sobre cómo almacenar los datos de tu aplicación no siempre requiere un motor de base de datos completo. He visto proyectos donde se despliega un PostgreSQL para manejar diez registros, y otros donde un archivo JSON gestiona cientos sin despeinarse. El problema no es la herramienta en sí, sino la falta de criterio para elegirla.

Mi regla es simple: la complejidad del almacenamiento debe ser proporcional a la complejidad de los datos y las operaciones que harás con ellos. Todo lo demás es sobreingeniería o una solución temporal que acabará reventando.

JSON: Cuándo usarlo y sus limitaciones

Un archivo JSON es, en esencia, una estructura de datos. Es ideal para guardar configuraciones, datos de pruebas, o pequeñas colecciones de información que no necesitan ser consultadas de forma compleja ni modificadas con mucha frecuencia por múltiples procesos. Su fortaleza es la inmediatez y la facilidad de lectura.

Cuando un cliente me llega con un requisito de datos simple, mi primera pregunta es si realmente necesita una base de datos. Si el volumen es bajo y la estructura es plana, un JSON puede ser más que suficiente. Piensa en una lista de productos para un catálogo estático o las credenciales de una API.

Funciona bien si:

Los datos son mayormente de lectura y no necesitan actualizaciones frecuentes.
El volumen de información es pequeño (cientos o pocos miles de registros).
No hay relaciones complejas entre los datos.
El acceso es mayormente monolítico (un solo proceso o script).

Deja de funcionar cuando:

Necesitas consultas complejas, filtrado o ordenación eficiente.
Múltiples procesos o usuarios intentan escribir al mismo tiempo, provocando conflictos.
El volumen de datos crece y el archivo JSON se vuelve demasiado grande para cargar en memoria.
Necesitas transacciones o integridad referencial.

SQLite: El punto intermedio, robusto y sin servidor

Cuando un JSON se queda corto pero no quieres la sobrecarga de un servidor de base de datos, SQLite es la respuesta. Es una base de datos relacional incrustada, lo que significa que es una librería que se integra directamente en tu aplicación, sin procesos de servidor separados.

Es como tener un pequeño almacén de datos dentro de tu propia aplicación, sin tener que preocuparte por la gestión de un servidor externo. Lo uso mucho en herramientas de línea de comandos, aplicaciones de escritorio y, sorprendentemente, en algunos microservicios donde cada servicio gestiona su propia base de datos local.

# Ejemplo de creación de tabla en SQLite
sqlite3 mi_aplicacion.db
CREATE TABLE usuarios (
    id INTEGER PRIMARY KEY,
    nombre TEXT NOT NULL,
    email TEXT UNIQUE
);
.quit

Bases de datos de servidor (PostgreSQL, MySQL, MongoDB): Para escalabilidad y datos complejos

Para proyectos con datos complejos, alto volumen, concurrencia o requisitos de escalabilidad, una base de datos de servidor es innegociable. PostgreSQL, MySQL, SQL Server o MongoDB ofrecen características como transacciones ACID, índices avanzados, replicación, sharding y gestión de usuarios que un JSON o SQLite no pueden dar.

La diferencia entre estas y las opciones anteriores no es solo la capacidad de almacenamiento, sino la robustez y la capacidad de operar en un entorno multiusuario y distribuido. Aquí es donde la decisión técnica se alinea con la arquitectura de la aplicación y las necesidades de rendimiento. Si tu código funciona en local con SQLite pero falla en producción con miles de usuarios, el problema no es solo el código, sino la elección de la base de datos. Puedes profundizar en estas diferencias en el artículo sobre por qué tu código funciona en local y falla en producción.

Compromisos en la elección del almacenamiento de datos

La elección del almacenamiento de datos siempre implica compromisos. No existe una solución única para todos los problemas.

Lo que ganas con JSON:

Simplicidad extrema, sin dependencias.
Facilidad de versionado con Git.
Rápida puesta en marcha.

Lo que complicas con JSON:

Dificultad para consultar y modificar datos a gran escala.
Ausencia de integridad de datos y transacciones.
Problemas de concurrencia y escritura simultánea.

Lo que ganas con SQLite:

Base de datos relacional completa en un solo archivo.
No necesita servidor, fácil de desplegar.
Buen rendimiento para volúmenes moderados.

Lo que complicas con SQLite:

Rendimiento limitado para alta concurrencia de escritura.
No es ideal para aplicaciones distribuidas o clusters.
La migración a una base de datos de servidor puede ser necesaria a futuro.

Lo que ganas con bases de datos de servidor (PostgreSQL, MongoDB):

Escalabilidad horizontal y vertical.
Alta concurrencia y transacciones robustas.
Herramientas de administración y monitorización avanzadas.

Lo que complicas con bases de datos de servidor:

Mayor complejidad de configuración y mantenimiento.
Requiere un servidor dedicado o un servicio gestionado.
Mayor consumo de recursos y, por tanto, mayor coste.

Mi recomendación es empezar con la solución más simple que cubra tus necesidades y estar preparado para escalar. No es una cuestión de “si”, sino de “cuándo” necesitarás pasar al siguiente nivel de complejidad.

Si estás pensando en cómo gestionar la persistencia de datos en entornos contenerizados, te interesará entender la diferencia entre volúmenes Docker vs bind mounts. Para proyectos más grandes, la decisión de la base de datos también influye en la arquitectura general; puedes leer sobre cuándo dividir un proyecto en microservicios y cuándo no para tener una visión más completa.