Token, JSON, SQLite o SQL: cuándo usar cada uno en tu web y por qué menos es más

Uno de los debates más frecuentes cuando se diseña una web o una webapp es el de la persistencia de datos: ¿usamos una base de datos? ¿Un fichero JSON? ¿SQLite? ¿Tokens? La respuesta correcta depende de qué problema estás resolviendo. Y en la mayoría de proyectos pequeños y medianos, la respuesta es: menos de lo que crees.

Por qué esta decisión importa más de lo que parece

Elegir mal la capa de persistencia al inicio de un proyecto tiene consecuencias duraderas: complejidad innecesaria, costes de hosting más altos, superficie de ataque mayor y problemas de escalabilidad en el peor momento. Y sobre todo, tiempo de desarrollo malgastado en infraestructura que no aporta valor real al usuario.

Mi posición es clara y la defiendo: la solución más simple que resuelve el problema es siempre la correcta. No la más potente, no la más escalable en teoría, no la que mejor queda en el CV. La más simple.

Tokens — para autenticación e identificación sin estado

Qué son

Un token es una cadena de texto (habitualmente JWT — JSON Web Token) que el servidor genera y envía al cliente. El cliente lo guarda y lo incluye en cada petición posterior. El servidor puede verificar el token sin consultar ninguna base de datos.

Cuándo usar tokens

• Autenticación en APIs y webapps: el usuario hace login, recibe un token, y ese token identifica sus peticiones sin que el servidor mantenga sesión.
• Acceso temporal a recursos: links de descarga, confirmaciones de email, invitaciones con caducidad.
• Comunicación entre servicios (API a API): sin interfaz de usuario, con autenticación machine-to-machine.

Cuándo NO usar tokens

Los tokens no son almacenamiento de datos. Si necesitas guardar el historial de acciones de un usuario, sus preferencias o cualquier información que persista más allá de la sesión, necesitas algo más. El token solo identifica; no almacena.

También hay que tener cuidado con la revocación: un JWT válido sigue siendo válido hasta que caduca, aunque el usuario haya cambiado la contraseña. Para casos donde la revocación inmediata es crítica, necesitas una lista negra o tokens de sesión más tradicionales.

JSON — para datos estáticos o de baja frecuencia de cambio

Qué es en este contexto

Un fichero JSON (o varios) como fuente de datos de una web estática o una webapp ligera. El catálogo de productos, la lista de ponentes de un congreso, el menú de un restaurante. Datos que cambian poco y que no requieren consultas complejas.

Cuándo usar JSON

• Catálogos de productos con menos de 500-1.000 items.
• Configuración de una webapp que no cambia en tiempo real.
• Datos que se actualizan manualmente o desde un proceso de build.
• Webs estáticas generadas: el JSON alimenta la generación y el resultado es HTML estático.

Las ventajas que se infravaloran

Un JSON se puede editar con cualquier editor de texto, se puede poner en un repositorio Git, se puede versionar, se puede auditar. No requiere servidor de base de datos, no tiene problemas de conexión, no tiene migraciones que gestionar. Para datos que no cambian en tiempo real, es frecuentemente la mejor opción.

Cuándo NO usar JSON

Cuando los datos cambian en tiempo real (stock, precios dinámicos, comentarios de usuarios). Cuando hay múltiples usuarios escribiendo simultáneamente: sin control de concurrencia, dos escrituras simultáneas pueden corromper el fichero. Cuando el volumen crece más allá de unos miles de registros: las consultas se vuelven lentas.

SQLite — la base de datos que cabe en un fichero

Qué es

SQLite es una base de datos relacional completa que se almacena en un único fichero. Sin servidor, sin proceso en segundo plano, sin configuración. Se incluye en el propio código de la aplicación. Es la base de datos más usada del mundo, aunque pocas personas lo saben: está en todos los iPhones, en todos los Android, en la mayoría de navegadores.

Cuándo usar SQLite

• Aplicaciones con un único usuario o con acceso concurrente bajo.
• Herramientas de escritorio o aplicaciones móviles.
• Prototipos y MVPs donde la simplicidad de despliegue es prioritaria.
• Datos que requieren consultas SQL pero el volumen no justifica un servidor de base de datos.
• Aplicaciones embebidas o en dispositivos con recursos limitados.
• Webs y webapps con tráfico bajo-medio y escrituras poco frecuentes.

El límite de SQLite que nadie menciona

SQLite maneja mal la concurrencia de escritura. Si múltiples usuarios escriben simultáneamente, genera bloqueos. Para lectura concurrente funciona perfectamente. Para escrituras frecuentes y simultáneas de muchos usuarios, empieza a tener problemas.

En la práctica, para la mayoría de webs y webapps pequeñas este límite nunca se alcanza. Una tienda con 50 pedidos al día no tiene escrituras simultáneas suficientes para saturar SQLite.

Por qué lo defiendo para proyectos medianos

SQLite elimina toda la complejidad operacional de una base de datos: sin servidor que mantener, sin backups complejos (el fichero se copia como cualquier otro), sin configuración de conexiones, sin problemas de versiones entre entornos. Para proyectos donde el equipo es pequeño y el tiempo de desarrollo es limitado, esa simplicidad tiene un valor enorme.

SQL completo (PostgreSQL, MySQL/MariaDB) — cuando realmente se necesita

Cuándo tiene sentido

• Escrituras frecuentes y concurrentes de muchos usuarios simultáneos.
• Volúmenes de datos que superan varios gigabytes.
• Consultas complejas con joins entre muchas tablas y optimización de índices.
• Replicación, alta disponibilidad o clusters distribuidos.
• Equipos con DBA dedicado que pueden gestionar la infraestructura.

El problema de usar SQL completo por defecto

La inercia lleva a muchos proyectos a usar MySQL o PostgreSQL por defecto, sin plantearse si realmente lo necesitan. El resultado: más complejidad de despliegue, más coste de hosting, más superficie de ataque, más cosas que mantener y actualizar. Y para proyectos con tráfico bajo, ninguna ventaja tangible.

El árbol de decisión que uso

1. ¿Los datos cambian en tiempo real con múltiples usuarios escribiendo?
   No → JSON o SQLite.
   Sí → SQLite (si el volumen es bajo) o SQL completo.
2. ¿Necesitas consultas complejas o relaciones entre entidades?
   No → JSON.
   Sí → SQLite o SQL completo.
3. ¿Cuántos usuarios simultáneos escribirán?
   Menos de 10-20 simultáneos → SQLite.
   Más → SQL completo.
4. ¿Solo necesitas identificar usuarios o sesiones?
   Sí → Tokens (JWT). Sin base de datos necesaria para esto.
5. ¿El volumen de datos supera los pocos GB?
   No → SQLite.
   Sí → SQL completo.

Aplicación práctica: los proyectos de Sibeos

En los proyectos que desarrollamos en Sibeos aplicamos este criterio de forma sistemática:

• Catálogos y webs de contenido (El Arepan Express, catálogos de producto): JSON estático. Actualización manual o desde un proceso automatizado. Sin base de datos.
• Agendas de eventos con asistente IA (WEF 2026): JSON para los datos del evento + token para identificar sesiones del asistente. Sin base de datos.
• Herramientas internas con usuarios y estado (Billing, dashboards): SQLite o PostgreSQL según el volumen esperado de escrituras concurrentes.
• Webapps con autenticación: JWT para la sesión + SQLite o SQL según los datos que haya que persistir.

La defensa de lo sobrio

Hay una tendencia en el mundo del desarrollo a sobredimensionar la infraestructura de datos por defecto. "¿Y si escala?" es la justificación habitual. Pero la realidad es que la mayoría de proyectos nunca llegan al punto donde SQLite deja de ser suficiente, y mientras tanto han pagado la complejidad de una infraestructura que no necesitaban.

La sobriedad técnica no es falta de ambición. Es elegir la herramienta adecuada para el problema real, no para el problema hipotético. Y eso, casi siempre, significa empezar con menos de lo que parece necesario.

Si tienes un proyecto donde no tienes claro qué capa de datos tiene sentido, cuéntanos el caso por WhatsApp. Es el tipo de decisión donde una conversación de 15 minutos puede ahorrar meses de trabajo mal orientado.

Preguntas frecuentes