Qué base de datos elegir para tu proyecto

Elegir la base de datos es una de las decisiones más difíciles de deshacer en un proyecto. Cambiar después significa reescribir consultas, migrar datos y volver a probar todo. Por eso vale la pena dedicar media hora a pensar antes de ejecutar el primer CREATE TABLE.

La buena noticia es que la elección rara vez es dramática. Cinco bases cubren casi todo lo que necesitan los bots, las APIs y los sitios web: PostgreSQL, MySQL, MongoDB, Redis y SQLite.

¿Qué criterios definen la elección?#

Cuatro preguntas resuelven la mayoría de los casos:

1. ¿Qué forma tienen los datos? Registros con columnas fijas y relaciones entre sí (usuarios, pedidos, productos) piden una base relacional. Documentos con campos que varían de un elemento a otro piden una base de documentos.
2. ¿Necesitas consistencia entre varias escrituras? Transferir saldo entre dos cuentas debe ocurrir completo o no ocurrir. Eso es una transacción, y las bases relacionales están construidas alrededor de ella.
3. ¿Cómo vas a leer los datos? Búsquedas por clave exacta muy rápidas (sesión, contador, cooldown) favorecen a Redis. Los informes que cruzan tablas favorecen a SQL.
4. ¿Cuántos procesos acceden a la base? Un solo proceso en la misma máquina puede usar un archivo (SQLite). Varios servidores o aplicaciones piden un servidor de base de datos accesible por red.

Responde estas cuatro y la lista de candidatas se reduce a una o dos.

¿Cuándo elegir PostgreSQL o MySQL?#

Son dos bases relacionales muy usadas. Guardan datos en tablas, relacionan tablas con claves foráneas y consultan todo con SQL. Ambas tienen transacciones completas: en MySQL, el motor por defecto InnoDB sigue el modelo ACID y soporta claves foráneas.

Elige una de ellas cuando los datos tienen estructura clara y relaciones: registro de usuarios, tienda en línea, sistema de suscripciones, economía de un bot con inventario y monedas. Es la apuesta segura si tienes dudas.

PostgreSQL ofrece extensiones, tipos avanzados y el tipo jsonb, que guarda JSON con soporte de índices. Eso permite mezclar columnas fijas con un campo flexible en la misma tabla:

CREATE TABLE productos (
  id      serial PRIMARY KEY,
  nombre  text NOT NULL,
  precio  numeric(10, 2) NOT NULL,
  extras  jsonb NOT NULL DEFAULT '{}'
);

CREATE INDEX productos_extras_idx ON productos USING GIN (extras);

INSERT INTO productos (nombre, precio, extras)
VALUES ('Camiseta', 19.90, '{"tallas": ["S", "M", "L"], "color": "negro"}');

SELECT nombre FROM productos WHERE extras @> '{"color": "negro"}';

MySQL es muy popular en servicios de hosting y en el ecosistema PHP, con muchas herramientas y tutoriales. Para un proyecto nuevo sin restricciones, la diferencia práctica entre las dos suele ser pequeña. Mira la comparación detallada en PostgreSQL o MySQL: cuál elegir.

¿Cuándo elegir MongoDB?#

MongoDB guarda documentos parecidos a JSON en colecciones, sin esquema obligatorio. Cada documento puede tener campos distintos y llevar listas y objetos anidados dentro.

Funciona bien cuando lees y escribes el objeto completo de una vez: configuraciones por servidor de Discord, perfiles con campos opcionales, catálogos donde cada elemento tiene atributos propios. La flexibilidad acelera el inicio del proyecto, porque cambiar el formato no exige una migración.

Dos precauciones. Primero, sin esquema, la validación pasa a ser tu responsabilidad (en el código o en reglas de validación de la base). Segundo, MongoDB soporta transacciones entre varios documentos, pero su propia documentación dice que, en la mayoría de los casos, cuestan más que las escrituras en un solo documento. Tampoco sustituyen un buen modelado, ya que los documentos embebidos reducen de por sí la necesidad de transacciones. Si ya estás escribiendo muchas relaciones y transacciones, probablemente quieres una base relacional. Mira qué es MongoDB y para qué sirve.

¿Cuándo elegir Redis?#

Redis guarda todo en memoria, con acceso por clave, y es muy rápido. Su papel clásico es ser la segunda base: caché de respuestas, sesiones, colas, contadores, límites de peticiones y cooldowns de comandos de bots.

Puede escribir en disco. La documentación oficial describe dos formas: RDB (instantáneas del conjunto de datos a intervalos) y AOF (un registro de cada escritura). Solo con RDB, una caída puede costar los últimos minutos de datos. Con AOF y la sincronización cada segundo por defecto, el riesgo baja a cerca de un segundo de escrituras. Aun así, Redis fue diseñado para datos que caben en memoria, así que no lo uses como base principal de datos que no puedes perder o que crecen sin parar.

Regla práctica: si perder el dato es una molestia (la caché se vuelve a calentar), Redis es ideal. Si perderlo es un perjuicio (pedidos, pagos), el dato vive en una base relacional o de documentos. Más en qué es Redis y para qué sirve.

¿Y SQLite?#

SQLite es una base de datos completa dentro de un archivo, sin servidor. La documentación del proyecto la presenta como alternativa a abrir archivos con fopen(), no como competidora de las bases cliente-servidor. Es excelente para prototipos, herramientas de línea de comandos, apps de escritorio y bots pequeños de un solo proceso.

El límite está en la concurrencia: SQLite acepta varios lectores, pero solo un escritor a la vez, y su documentación aconseja evitar que varios equipos accedan directamente al mismo archivo por red. Cuando tu proyecto pase a tener más de un servidor o muchas escrituras simultáneas, migra a PostgreSQL o MySQL. Empezar con SQLite y migrar después es un camino legítimo, siempre que uses SQL estándar y evites funciones exclusivas.

¿Qué base para cada tipo de proyecto?#

Ante la duda, elige PostgreSQL. Cubre el caso relacional y buena parte del caso flexible, y rara vez alguien se arrepiente de elegirla.

Cómo hacerlo en Square Cloud#

Las bases cliente-servidor de la tabla (MongoDB, PostgreSQL, MySQL y Redis) tienen hosting en Square Cloud desde el plan Standard; el Hobby no incluye bases de datos. Creas la base en el panel (nombre, memoria y motor), y queda lista en segundos en el mismo datacenter que tus aplicaciones, con una latencia media de cerca de 1 ms y TLS obligatorio. Si sigues el "ante la duda, PostgreSQL", ten en cuenta que es el PostgreSQL nativo, sin extensiones.

El patrón de las preguntas frecuentes, datos permanentes en una base relacional y Redis como caché o cola, cabe en un solo plan. Motores distintos conviven, limitados solo por la RAM del plan: como mínimo 1024 MB para PostgreSQL, MySQL y MongoDB y 512 MB para Redis. Un PostgreSQL y un Redis juntos ocupan 1,5 GB de los 4 GB del Standard de entrada. Cada uno tiene su propia URL de conexión, que el panel te entrega y tú guardas en una variable de entorno de la aplicación.

SQLite también tiene su lugar: el disco de cada aplicación persiste entre reinicios y deploys, así que un bot de un solo proceso puede guardar ahí su archivo .db. Deja ese archivo fuera del ZIP de deploy, porque un commit sobrescribe los archivos que vienen en el paquete. El criterio 4 sigue valiendo: las aplicaciones en un load balancing no comparten disco, así que, a partir de dos procesos, el camino es una base de datos servidor.

Para los datos que no pueden perderse, puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos hace también un snapshot automático diario. Consulta las bases disponibles hoy en Bases de datos.