Guía práctica para elegir una base de datos según rutas de lectura/escritura, latencia, consistencia y necesidades de crecimiento—para que las tendencias no generen deuda técnica evitable.
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.
Una carga de trabajo es el comportamiento real de tu sistema en producción:
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.
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.
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”).
La mayoría del tráfico de lectura cae en unos cuantos patrones reconocibles:
Un feed social mezcla estas formas: búsquedas puntuales para perfiles, lecturas por rango para “últimas publicaciones” y agregaciones para contar.
Los patrones de escritura importan igual:
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).
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.
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 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.
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.
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.
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”.
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 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.
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.
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:
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.
Un patrón de acceso es la forma repetible en que tu aplicación toca los datos en producción: qué lee/escribe, con qué frecuencia, qué latencias y en qué formas de consulta (búsquedas puntuales, lecturas por rango, joins, agregaciones, ventanas temporales, etc.). Es más accionable que “tenemos usuarios y pedidos”, porque se mapea directamente a índices, decisiones de esquema y ajuste de la base de datos.
Porque “popular” refleja las restricciones de otros equipos, no las tuyas. La misma base de datos puede ser ideal para una carga (p. ej., OLTP) y problemática para otra (p. ej., análisis pesado). Empieza listando tus principales 5–10 lecturas y escrituras, y evalúa las bases de datos por esos comportamientos en lugar de por el ruido de mercado.
Apunta primero:
Esto se convierte en tu documento de requisitos para comparar opciones.
OLTP son muchas operaciones pequeñas, concurrentes y sensibles a la corrección (checkout, actualizaciones de inventario, cambios de cuenta) donde importan las transacciones y restricciones.
OLAP/analítica son consultas menos frecuentes que tocan muchos datos (scans, group-bys, dashboards) donde latencias de segundos pueden ser aceptables pero las lecturas pesadas son caras.
Ejecutarlas ambas en un mismo sistema suele hacer que las consultas analíticas perjudiquen la latencia de las operaciones orientadas al usuario.
Mira p95/p99, no promedios. Si el 1% más lento de las solicitudes tarda segundos, los usuarios percibirán la app como poco fiable aunque el promedio parezca bueno.
Consejo práctico: monitoriza p95/p99 por endpoints críticos (login, checkout, búsqueda) y correlaciónalos con métricas de base de datos (bloqueos, lag de replicación, saturación de I/O).
Suelen tener necesidades contrapuestas:
Usar almacenes especializados puede ser más sencillo en conjunto que forzar una sola base de datos a hacerlo todo con soluciones alternativas.
La caché puede hacer que una carga de solo-lectura parezca menor hasta que hay un miss o un purgado. Eso cambia lo que importa:
Una caché puede ocultar problemas temporalmente, pero también crear fallos bruscos si los misses saturan la base de datos.
La corrección fuerte implica garantías sobre transacciones y visibilidad de actualizaciones (no ver estados “medio escritos”). Es crucial para pagos, saldos, inventario y reservas.
Los trade-offs incluyen:
Define qué datos son “nunca deben estar equivocados” frente a lo que puede tolerar cierto desfase.
Los índices son el contrato de rendimiento entre tu carga y la base de datos. Planifica índices para filtros frecuentes (WHERE), ordenaciones (ORDER BY), claves de join y consultas por rango temporal.
Pero los índices consumen almacenamiento y pueden empeorar las escrituras (amplificación de escritura). La meta es indexar lo que realmente haces a menudo, no todo.
Trata un PoC como un pequeño ensayo de producción:
Si no cumple un requisito imprescindible en el PoC, elimínalo pronto.
