Elige bases de datos por patrones de acceso, no por tendencias de la industria

Empieza por la carga de trabajo, no por el bombo

Elegir una base de datos porque es “popular” es como comprar un vehículo porque todo el mundo habla de él, sin comprobar si necesitas una moto, una camioneta o un autobús. Las tendencias reflejan lo que funcionó para el producto, tamaño de equipo, presupuesto y tolerancia al riesgo de otra gente. Tu base de datos debe encajar con tu carga de trabajo: lo que tu aplicación hace realmente todo el día.

Qué entendemos por “carga de trabajo”

Una carga de trabajo es el comportamiento real de tu sistema en producción:

• Cómo se escribe la información: actualizaciones pequeñas y frecuentes, inserciones por lotes grandes, eventos append-only o ediciones ocasionales.
• Cómo se lee: búsquedas por registro, feeds de “últimos N”, búsqueda de texto completo o escaneos grandes.
• Cómo se consulta: lecturas clave-basadas simples, filtros multi-campo, joins, agregaciones, reportes por ventanas temporales o consultas geoespaciales.
• Cómo cambia con el tiempo: picos de tráfico, estacionalidad, backfills y crecimiento del volumen de datos.

Estos comportamientos son tus patrones de acceso: las formas repetibles en que tu app interactúa con los datos. Si puedes describirlos con claridad, la selección de la base de datos deja de ser un misterio.

Establece las expectativas correctas desde el principio

Una talla rara vez sirve para todo. Muchos sistemas exitosos usan un enfoque híbrido: una base de datos optimizada para transacciones, otra para analítica y, a veces, un motor de búsqueda o una caché dedicada. Eso no es “complejidad extra por el gusto de hacerlo”: es reconocer que diferentes patrones de acceso se benefician de distintos motores de almacenamiento y consulta.

Antes de debatir “SQL vs NoSQL” o perseguir lo que esté de moda, anota tus 5–10 lecturas y escrituras más importantes. Empieza por ahí; todo lo demás son detalles.

Qué significa realmente “patrón de acceso”

Un patrón de acceso es la descripción práctica de cómo tu aplicación toca los datos día a día: qué lee, qué escribe, con qué frecuencia, qué rapidez y en qué formas. Es menos sobre qué son los datos (“órdenes” o “usuarios”) y más sobre lo que haces con ellos (“buscar la orden por ID 10.000 veces por minuto” o “escanear todas las órdenes del mes pasado para generar un informe”).

Lecturas: tres formas comunes

La mayoría del tráfico de lectura cae en unos cuantos patrones reconocibles:

• Búsquedas puntuales: “Muéstrame la orden #12345” o “Carga este perfil de usuario.” Son rápidas si la base de datos puede usar un índice o clave.
• Consultas complejas: “Encuentra clientes que compraron X, en la región Y, con devoluciones > 2.” Dependen de joins, filtros, ordenaciones y un buen plan de consultas.
• Escaneos / lecturas por rango: “Obtener todos los logs de las últimas 24 horas” o “Listar las últimas 50 transacciones.” Esto puede implicar leer muchas filas/documentos aunque muestres solo una porción.

Un feed social mezcla estas formas: búsquedas puntuales para perfiles, lecturas por rango para “últimas publicaciones” y agregaciones para contar.

Escrituras: inserciones, ingesta y actualizaciones

Los patrones de escritura importan igual:

• Inserciones de una fila: crear una orden, añadir un comentario, registrar un usuario.
• Ingesta de alto volumen: recoger eventos de clic o logs continuamente.
• Actualizaciones: cambiar conteos de inventario, actualizar estado de una orden, editar una publicación.

Los logs suelen ser “write-heavy y append-only” (muchas inserciones, pocas actualizaciones). Las órdenes suelen ser “se escribe y luego se actualiza” (creación, luego cambios de estado).

Cargas mixtas (y por qué son complicadas)

Muchos productos quieren todo a la vez: lecturas puntuales rápidas para la app, consultas complejas para soporte y escaneos grandes para analítica. Una base de datos puede manejar ciertas mezclas, pero algunas combinaciones se enfrentan entre sí: por ejemplo, escaneos analíticos pesados pueden ralentizar lecturas sensibles a latencia que alimentan el checkout o un feed.

Cuando puedes nombrar claramente tus patrones de acceso, puedes evaluar bases de datos por comportamiento real en vez de por popularidad.

Tipos comunes de cargas para identificar temprano

Antes de comparar marcas de bases de datos, nombra la carga que realmente sirves. La mayoría de los productos no son “una sola carga”: son varias cargas distintas convivendo (y a veces compitiendo). Clasificarlas bien desde el principio evita forzar una base de datos a un trabajo para el que no está optimizada.

OLTP (Online Transaction Processing)

OLTP es el latido diario de la mayoría de las apps: muchas lecturas y escrituras pequeñas, muchos usuarios concurrentes y peticiones que deben terminar rápido.

Piensa en: “actualizar un carrito”, “crear una orden”, “cambiar una dirección”, “comprobar inventario.” Estas operaciones son cortas, específicas y sensibles a la corrección. Si se captura un pago, no debe desaparecer; si se reserva un asiento, no deben reservarlo dos personas.

OLTP suele empujarte hacia sistemas que manejan bien la alta concurrencia y ofrecen garantías claras sobre transacciones e integridad de datos.

Analítica / OLAP (reportes y agregaciones)

La analítica invierte la forma del trabajo: menos consultas, pero cada una toca mucha más información.

Piensa en: “ingresos por región el último trimestre”, “conversión por canal”, “mejores productos por categoría”, “tendencia de usuarios activos diarios.” Estas consultas suelen escanear muchas filas, agrupar, agregar y ordenar. Las expectativas de latencia pueden ser más laxas (segundos pueden estar bien), pero el coste de escaneos pesados importa —especialmente si los dashboards se ejecutan todo el día.

Si intentas ejecutar consultas OLAP en el mismo sistema que maneja el checkout, a menudo uno de los dos sufre.

Series temporales y logging

Las series temporales y los logs suelen ser append-heavy: llegan eventos nuevos constantemente y normalmente consultas por rangos temporales.

Piensa en: métricas, clickstreams, telemetría de dispositivos, logs de auditoría. Necesidades comunes incluyen políticas de retención (borrar/expirar datos antiguos), rollups (guardar raw por 7 días, agregados por 12 meses) y escrituras rápidas durante picos.

Esta carga importa menos por joins complejos y más por ingerir eficientemente muchos registros con timestamps y mantener el almacenamiento predecible en el tiempo.

Búsqueda

La búsqueda no es solo “encontrar filas”. Es coincidencia de texto, ranking por relevancia, coincidencias parciales y filtrado amigable para el usuario.

Piensa en: buscar productos por palabras clave, encontrar tickets por frases, filtrar por facetas (marca, rango de precio, color) y ordenar por “mejor coincidencia.” Estas funciones suelen requerir indexación y capacidades de consulta especializadas que las bases de datos de propósito general pueden aproximar, pero rara vez dominan.

Si la búsqueda es una característica central, trátala como su propia carga desde el inicio, no como un detalle que “añadiremos después”.

Necesidades de rendimiento: latencia, rendimiento y picos

El rendimiento no es un solo número. Dos bases de datos pueden ser ambas “rápidas” y sentirse completamente distintas para usuarios y operadores. Para elegir bien, separa lo que experimentan los humanos (latencia) de lo que debe sostener el sistema (throughput), y prueba tus supuestos con picos.

Latencia vs throughput: lo que notan los usuarios vs lo que soporta el sistema

Latencia es cuánto tarda una única petición —“tocas el botón, obtienes resultado.” Los usuarios notan la latencia directamente.

Throughput es cuántas peticiones puedes procesar por segundo —cuánto tráfico puede manejar el sistema en total.

Una base de datos puede ofrecer alto throughput mediante batching eficiente, pero aún tener retraso por petición. Otra puede optimizar lecturas puntuales rápidas y fallar cuando llegan muchas escrituras a la vez.

Por qué importa el 1% más lento (P99)

El promedio de latencia oculta el dolor. Si 99 solicitudes terminan en 50 ms y 1 tarda 2 segundos, el promedio parece bien —pero ese 1% es el “la app está lenta” para el usuario.

Eso es lo que mide la latencia P99: el tiempo que tardan las solicitudes del 1% más lentas. Para características visibles (checkout, login, búsqueda), P99 suele ser la métrica que decide si el diseño de la base de datos se percibe como fiable.

Carga pico vs promedio: diseñar para picos

La mayoría de los sistemas no fallan en el tráfico promedio; fallan durante picos: un email de marketing, una noticia de última hora, día de nómina, cierre de mes.

Los picos cambian la conversación sobre la base de datos:

• Índices que funcionan a 200 writes/s pueden ser un cuello de botella a 2.000 writes/s.
• Trabajo en segundo plano (compaction, vacuum, replicación) compite con consultas de usuarios justo cuando menos lo deseas.

Cómo la caché cambia la forma de las lecturas

La caché puede hacer que las cargas intensas de lectura parezcan menores —hasta que hay un miss o un vaciado de caché.

Si la mayoría de lecturas golpean la caché, tu base de datos sirve principalmente escrituras y lecturas ocasionalmente caras. Eso favorece distintas elecciones que un sistema donde cada lectura accede a la base de datos. Planea para eventos de “cache fría” y la latencia cola de misses, no solo para el camino feliz.