Guía para elegir entre 6 tipos de bases de datos

Al finalizar este tema

Podrás determinar qué base de datos elegir según el tamaño del proyecto y la naturaleza de los datos.

Has comenzado un proyecto personal

Quieres crear un foro. Si buscas en Google, encontrarás más de 10 opciones: MySQL, PostgreSQL, MongoDB, Firebase, Supabase, Redis, CockroachDB...

Como no sabes cuál usar, instalas MySQL por ser la que más aparece. Mucho tiempo después, piensas: "Esto sería mejor con PostgreSQL...", y comienza el infierno de la migración.

Si eliges bien desde el principio, esto no sucederá. La pregunta clave es una sola: "¿Mis datos tienen forma de tabla o no?"

Datos con forma de tabla → SQL (relacionales)

Usuarios, publicaciones, comentarios, pedidos... los datos que se organizan en filas y columnas son adecuados para una base de datos relacional.

text

tabla de usuarios
┌────┬────────┬──────────────────┐
│ id │ name   │ email            │
├────┼────────┼──────────────────┤
│ 1  │ Cheolsu   │ cs@email.com     │
│ 2  │ Younghee   │ yh@email.com     │
└────┴────────┴──────────────────┘

MySQL

La base de datos relacional más utilizada. Es lo primero que encontrarás al iniciarte en el desarrollo web. WordPress, las tiendas online y la mayoría de los servicios web utilizan MySQL. Es estable y cuenta con una gran comunidad, pero se queda atrás de PostgreSQL en el procesamiento de JSON y funciones avanzadas.

PostgreSQL

Puedes considerarlo como un "MySQL avanzado". Ofrece soporte para tipos JSON, búsqueda de texto completo, datos geográficos (PostGIS) y tipos de arreglos; sus funcionalidades son mucho más amplias. Si los datos son complejos o requieren una gran escalabilidad, PostgreSQL es la mejor opción. Supabase también está basado en PostgreSQL.

SQLite

No requiere instalación. Un solo archivo constituye la base de datos. Al no contar con un servidor, no es adecuado para servicios web con muchas conexiones simultáneas, pero es ideal para bases de datos integradas en aplicaciones móviles, prototipos y pruebas.

Datos no estructurados → NoSQL

Mensajes de chat, datos de sensores IoT, registros de actividad de usuarios: cuando los datos no tienen una estructura fija o cambian rápidamente, NoSQL es la opción correcta.

MongoDB

Almacena documentos JSON (BSON) tal cual. Su esquema es flexible, lo que permite añadir o eliminar campos libremente. Permite un prototipado rápido, pero no es adecuado para datos que requieren JOINs complejos.

javascript

// MongoDB — colocar todos los datos relacionados en un solo documento
{
  "_id": "user_001",
  "name": "Cheolsu",
  "posts": [
    { "title": "Primer artículo", "date": "2026-07-01" },
    { "title": "Segundo artículo", "date": "2026-07-02" }
  ]
}

Redis

Se almacena en la memoria (RAM). Al ser memoria y no disco, las operaciones de lectura/escritura son extremadamente rápidas. Se utiliza para caché, almacenamiento de sesiones y rankings en tiempo real. No es un almacenamiento permanente, sino que cumple una función auxiliar.

BaaS — Base de datos sin servidor

Firebase / Supabase

Permiten accedencia directa a la DB desde el frontend sin necesidad de crear un servidor backend. Ofrecen autenticación, sincronización en tiempo real y almacenamiento de archivos. Son ideales para desarrolladores individuales o prototipos.

Firebase → NoSQL (Firestore), ecosistema de Google
Supabase → PostgreSQL, código abierto, soporte SQL

Cheat sheet de selección

Pregunta	Recomendación
Primer proyecto, quiero lanzarlo rápido	Supabase o Firebase
Servicio web, datos en formato de tabla	PostgreSQL (MySQL también es OK)
La estructura de los datos cambia con frecuencia	MongoDB
Caché / Sesiones / Rankings en tiempo real	Redis (+ DB principal aparte)
Integrado en aplicaciones móviles	SQLite
El servicio ya es grande y complejo	PostgreSQL

No hay una respuesta correcta. Sin embargo, PostgreSQL es tan versátil que existe el dicho: "Si no lo sabes, usa PostgreSQL".

No hay por qué usar solo una

En servicios reales, se combinan varias bases de datos: