Resumen ejecutivo

• Las bases de datos no son “una sola herramienta”: hay relacionales (SQL), documentales, clave-valor, grafo y warehouses en la nube, y cada una encaja mejor con un tipo de problema.

• PostgreSQL y similares brillan cuando necesitás integridad, relaciones y transacciones; MongoDB cuando el dato vive como documento flexible; Redis cuando necesitás velocidad en memoria (caché, sesiones, contadores).

• Los warehouses (BigQuery, Redshift, Snowflake) no reemplazan la base operativa: sirven para analítica a gran escala sin pegarle a producción.

• Si estás entrando a data, conviene empezar por SQL y entender cuándo sumar NoSQL o la nube, no memorizar nombres de productos.

Cuando alguien dice “necesitamos una base de datos”, casi siempre está eligiendo sin decirlo entre varios mundos distintos. Un ecommerce de pedidos no se modela igual que un feed de notificaciones, un grafo de recomendaciones o un tablero de BI con millones de filas. Esta guía es la pieza pilar: qué es cada tipo, un ejemplo de cuándo usarlo y qué roles lo tocan día a día. ¿Por qué ahora? Porque “base de datos” sigue siendo una búsqueda masiva en Argentina y, al mismo tiempo, los equipos mezclan SQL, NoSQL y cloud warehouse sin un mapa claro. Si querés profundizar el contraste clásico, arrancá también por SQL vs NoSQL: cuándo usar cada uno.

Bases de datos relacionales (SQL)

Las bases relacionales organizan la información en tablas con filas y columnas, claves primarias/foráneas y un lenguaje estándar: SQL. PostgreSQL, por ejemplo, se define como un sistema objeto-relacional open source con consultas complejas, foreign keys, triggers, vistas actualizables e integridad transaccional. MySQL, SQL Server y Oracle viven en la misma familia conceptual.

Cuándo usarlas: pedidos, facturación, usuarios, inventario, nómina o cualquier dominio donde las relaciones importan y no podés “perder” consistencia. Si necesitás que un pago y la actualización del stock ocurran juntos o no ocurran, el modelo relacional es el default seguro.

Quién las toca: analistas de datos, data engineers, backend developers y BI analysts. Si estás arrancando, aprender SQL desde cero es el atajo más rentable.

Bases documentales (NoSQL)

En MongoDB y similares, el registro es un documento (parecido a JSON): campos y valores, con documentos embebidos y arrays. La documentación oficial de MongoDB destaca que ese modelo reduce joins costosos y permite un esquema dinámico cuando la forma del dato cambia seguido.

Cuándo usarlas: catálogos de productos con atributos variables, CMS, perfiles de usuario con campos opcionales, eventos de apps o IoT donde cada payload no es idéntico al anterior. Si tu acceso natural es “traer este documento completo por ID”, el modelo documental encaja.

Cuidado: no es “más moderno = mejor”. Si tu problema es reporting con joins pesados y reglas de negocio rígidas, forzar documentos suele doler más adelante.

Clave-valor e in-memory: Redis y familia

Redis se presenta como un in-memory data structure store: guardás valores bajo una clave y recuperás en milisegundos. En la guía oficial de Redis el patrón base es SET/GET (y hashes, listas, sets, etc.) para inventarios, objetos y contadores.

Cuándo usarlo: caché de respuestas, sesiones de login, rate limiting, colas ligeras, leaderboards y contadores en tiempo real. Casi nunca reemplaza a la base de verdad: vive al lado de PostgreSQL o MongoDB para acelerar lo caliente.

Quién lo toca: backend, platform/SRE y a veces data engineers que cachean resultados de queries caras.

Grafos: cuando la relación es el dato

En bases de grafo (Neo4j y similares) el foco son nodos y aristas: personas que siguen a personas, productos relacionados, fraudes entre cuentas. No las necesitás para un CRUD simple; sí cuando las consultas tipo “amigos de amigos” o “camino más corto” son el corazón del producto.

Ejemplo: motor de recomendaciones sociales, detección de fraude en redes de transacciones, knowledge graphs para búsqueda interna.

Warehouses en la nube: analítica sin tumbar producción

BigQuery (Google Cloud), Amazon Redshift y Snowflake son warehouses: pensados para consultas analíticas sobre volúmenes grandes, no para el checkout de tu app. La idea típica es: la base operativa (Postgres/Mongo) recibe las transacciones; un pipeline (batch o CDC) copia o transforma datos hacia el warehouse; ahí corren dashboards, cohortes y modelos.

Cuándo usarlos: reportes de negocio, exploración de históricos, ML features a escala, dashboards que no pueden vivir sobre la base de producción. Cuándo no: como única base de una app transaccional.

Si querés el fundamento relacional antes de saltar a cloud, repasá qué son las bases de datos relacionales.

Cómo elegir sin paralizarte (checklist rápido)

1. ¿Necesito transacciones y relaciones fuertes? → Relacional (PostgreSQL u otra SQL).

2. ¿El dato es un documento con forma variable? → Documental (MongoDB u otra).

3. ¿Necesito latencia ultra baja para lecturas/escrituras simples? → Clave-valor / Redis como capa.

4. ¿La pregunta es “cómo se conectan las entidades”? → Grafo.

5. ¿La carga es analítica masiva? → Warehouse en la nube, no la base de la app.

En la práctica, los equipos maduros usan más de una: Postgres + Redis + BigQuery es un stack común, no una contradicción.

Cursos recomendados de Coderhouse

Para armar criterio de datos de punta a punta, el Curso de Data Analytics te deja con SQL, análisis y proyectos que podés mostrar. Si buscás un camino más largo hacia roles de data, mirá la Carrera de Data Analytics.

CTA: esta semana elegí un problema real de tu trabajo o side project y anotá en una hoja: tipo de dato, consultas frecuentes y si necesitás transacciones. Con eso solo ya sabés si tu próximo paso es SQL, un documental o un warehouse.

Preguntas frecuentes

¿Debo aprender SQL o NoSQL primero? SQL primero. Es el lenguaje más pedido en analítica y backend, y te da el marco para entender cuándo NoSQL aporta de verdad.

¿MongoDB reemplaza a PostgreSQL? No de forma automática. Son modelos distintos. Muchos productos usan ambos según el dominio.

¿Redis es una base de datos “completa”? Es un store en memoria excelente como caché y para estructuras rápidas. Para datos críticos de largo plazo suele acompañar a otra base persistente.

¿Un warehouse sirve para la app en producción? No como sistema de registro de transacciones. Sirve para analítica; las escrituras operativas van a otra base.