Cómo los LLMs mapean las necesidades del producto a la elección de bases de datos, qué pasan por alto y una lista práctica para validar recomendaciones antes de comprometerte con un stack.
Los equipos piden a los LLMs que recomienden una base de datos por la misma razón por la que les piden redactar correos o resumir especificaciones: es más rápido que empezar desde cero. Cuando te enfrentas a una docena de opciones —PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse y más— un LLM puede generar rápidamente una lista corta, esbozar compensaciones y ofrecer un punto de partida “suficientemente bueno” para la discusión del equipo.
Usado bien, esto también te obliga a articular requisitos que de otra forma podrías mantener vagos.
En términos simples, describes el producto (“un marketplace con anuncios y chat”), los datos (“usuarios, órdenes, mensajes”) y las restricciones (“debe escalar a 1M de usuarios, necesita búsqueda rápida, bajo esfuerzo operativo”). El LLM entonces mapea esas necesidades a patrones arquitectónicos comunes:
Ese mapeo puede ser realmente útil al principio, especialmente cuando la alternativa es una página en blanco.
Una recomendación de LLM se debe tratar como una hipótesis, no como un veredicto arquitectónico. Puede ayudarte a:
Pero no puede conocer la forma real del tráfico, el crecimiento de datos, las habilidades del equipo, las limitaciones de proveedor o la tolerancia operativa sin entradas cuidadosas —y aun así no ejecutará pruebas en producción.
Los LLMs tienden a fallar de formas previsibles: apoyándose en reglas empíricas populares, adivinando detalles que faltan, pasando por alto transacciones y necesidades de consistencia, asumiendo rendimiento sin benchmarks y subestimando coste y carga operativa.
El resto de este artículo desglosa esos modos de fallo y termina con una lista de verificación práctica para validar cualquier consejo de base de datos de un LLM antes de comprometerte con un stack.
Cuando le pides a un LLM que “recomiende una base de datos”, no evalúa las bases de datos como lo haría un ingeniero. Convierte tu prompt en requisitos inferidos, los empareja con patrones que ha visto antes y luego produce una respuesta que suena como una decisión.
Las entradas no son sólo los detalles explícitos que proporcionas (tráfico, tamaño de datos, necesidades de consistencia). El modelo también usa:
Como muchos prompts están incompletos, el modelo a menudo rellena huecos con suposiciones implícitas —a veces correctamente, a veces no.
La mayoría de respuestas aterrizan en tres capas:
El resultado puede sentirse como una recomendación clara, pero a menudo es un resumen estructurado de opciones convencionales.
Los LLMs generalizan a partir de ejemplos; no ejecutan tu carga, no inspeccionan tu esquema ni benchmarkean consultas. Si los datos de entrenamiento asocian fuertemente “alta escala” con “NoSQL”, podrías obtener esa respuesta incluso cuando un sistema SQL bien afinado encajaría mejor.
El lenguaje confiado es un estilo, no una medición. A menos que el modelo indique explícitamente sus suposiciones ("asumo escrituras mayormente append-only y que la consistencia eventual es aceptable"), la certeza puede ocultar la incertidumbre real: entradas faltantes y afirmaciones de rendimiento no probadas.
Cuando la gente dice “elige una base de datos según las necesidades del producto”, a menudo se refiere a mucho más que “almacenamos usuarios y órdenes”. Una buena elección refleja lo que el producto hace, cómo debe comportarse bajo estrés y lo que tu equipo puede operar razonablemente.
Empieza por la forma del producto: las entidades clave, cómo se relacionan y qué consultas alimentan los flujos reales.
¿Necesitas filtrado y reporting ad-hoc sobre muchos atributos? ¿Te apoyas en joins entre relaciones? ¿Lees mayoritariamente un registro por ID o escaneas rangos temporales? Estos detalles determinan si encajan mejor tablas SQL, modelos documentales, patrones wide-column o índices de búsqueda.
Las bases de datos se eligen tanto por restricciones como por características:
Un sistema que tolera unos segundos de retraso es muy distinto a uno que debe confirmar un pago en menos de 200 ms.
Incluso un modelo de datos “perfecto” falla si las operaciones no encajan:
Los requisitos de cumplimiento pueden acotar opciones rápidamente:
Los LLMs suelen inferir estas necesidades a partir de prompts vagos —ser explícito aquí marca la diferencia entre una recomendación útil y un error confiado.
Los LLMs suelen mapear unas pocas necesidades declaradas (“tiempo real”, “escala”, “esquema flexible”) a una etiqueta familiar (“usar NoSQL”, “usar Postgres”). Eso puede ser útil para brainstorming, pero el razonamiento se desvía cuando el modelo trata las características de una base de datos como si fueran lo mismo que los requisitos del producto.
Una lista de características (transacciones, soporte JSON, búsqueda de texto completo, sharding) suena concreta, pero las necesidades del producto generalmente describen resultados: latencia aceptable, reglas de corrección, auditabilidad, habilidades del equipo, limitaciones de migración y presupuesto.
Un LLM puede “marcar” características y aun así pasar por alto que el producto necesita flujos de soporte previsibles, un ecosistema maduro o una opción de hosting que tu empresa pueda usar.
Muchas recomendaciones asumen que si una base de datos puede almacenar un tipo de dato, servirá bien al producto. La parte difícil es la relación entre los datos y las consultas: cómo filtrarás, unirás, ordenarás y agregarás —a qué volúmenes y con qué patrones de actualización.
Dos sistemas que ambos “almacenan eventos de usuario” pueden comportarse muy distinto según necesites:
Un LLM puede decir “La base de datos X es rápida”, pero el rendimiento depende del diseño del esquema, índices, particionamiento, patrones de consulta y concurrencia. Cambios pequeños —como añadir un índice compuesto o evitar escaneos sin límite— pueden invertir el resultado. Sin datos y consultas representativas, “rápido” es solo una conjetura.
Aunque dos bases de datos puedan técnicamente cumplir requisitos, la mejor elección puede ser la que tu equipo pueda operar con fiabilidad: backups y tiempo de restauración, monitorización, carga de on-call, vendor lock-in y predictibilidad de costes.
Los LLMs tienden a subvalorar estas realidades a menos que las proporciones explícitamente.
Los LLMs responden a menudo a preguntas de bases de datos con “reglas” repetidas, como "NoSQL escala mejor" o "Postgres lo puede hacer todo". Estos atajos suenan seguros, pero aplastan la realidad desordenada: qué almacenas, cómo lo consultas y qué ocurre cuando falla.
Un patrón común es asumir que si mencionas crecimiento, alto tráfico o “big data”, la elección más segura es NoSQL. El problema es que "escalar" rara vez es el primer problema sin resolver". Muchas apps topan con límites por:
En esos casos, cambiar de base de datos no arregla la causa raíz —solo cambia las herramientas.
Las reglas empíricas también obvian requisitos que influyen mucho en el encaje. Un LLM podría recomendar un almacén documental sin contemplar que necesitas:
Esos requisitos no descartan automáticamente NoSQL, pero elevan la complejidad: puede que necesites diseño de esquema cuidadoso, lógica adicional en la aplicación o compromisos distintos a los que el LLM implicó.
Cuando una recomendación se basa en un eslogan en vez de en tus patrones de acceso, el riesgo no es solo una elección subóptima: es una replatformación costosa más tarde. Migrar datos, reescribir consultas y reentrenar al equipo suele ocurrir cuando menos puedes permitirte tiempo de inactividad.
Trata las “reglas” como preguntas que hacer, no como respuestas. Pregunta qué estás escalando (lecturas, escrituras, analítica), qué debe ser correcto y qué consultas son inevitables.
Los LLMs son buenos convirtiendo una descripción corta en una elección segura de base de datos—pero no pueden inventar las restricciones faltantes que realmente determinan si una elección funciona. Cuando las entradas son vagas, la recomendación se vuelve una suposición con apariencia de respuesta.
Palabras como “tiempo real”, “alto tráfico”, “escalable” o “enterprise-grade” no se traducen limpiamente a una base de datos específica. “Tiempo real” puede significar “actualizaciones en 5 segundos” para un dashboard o “sub-50ms end-to-end” para alertas de trading. “Alto tráfico” pueden ser 200 requests por segundo o 200,000.
Sin números duros, un LLM puede recurrir a heurísticas populares (por ejemplo, “NoSQL para escala”, “Postgres para todo”) aun cuando las necesidades reales apunten a otra dirección.
Si no provees estos, el modelo los asumirá en silencio:
Las omisiones más dañinas suelen ser las moldeadas por consultas:
Una base de datos que sobresale en acceso key-value puede tener problemas cuando el producto necesita de pronto filtrado flexible y reporting fiable.
Trata la “selección de base de datos” como una interacción en dos pasos: primero recopila las restricciones, luego recomienda. Un buen prompt (o una checklist interna) debería requerir números y consultas de ejemplo antes de nombrar cualquier motor.
Un error común del LLM es recomendar una categoría de base de datos (SQL, documental, gráfico, wide-column) sin validar si los datos del producto realmente encajan en ese modelo. El resultado es elegir un almacén que suena adecuado para la carga, pero que lucha con la estructura de la información que necesitas representar.
Los LLMs con frecuencia pasan por alto la profundidad y cardinalidad de las relaciones: uno-a-muchos vs muchos-a-muchos, propiedad anidada, entidades compartidas y con qué frecuencia los usuarios las recorren.
Una base documental puede parecer natural para “perfiles de usuario”, pero si tu producto responde constantemente consultas cross-entity —“todos los proyectos donde cambió el rol de algún miembro en los últimos 7 días” o “las 20 etiquetas más usadas entre equipos filtradas por estado de cumplimiento”— ya no estás solo fetchando documentos; estás haciendo joins.
Cuando esos joins son frecuentes, o bien:
Duplicar no es gratis. Aumenta la amplificación de escrituras, complica las actualizaciones para mantener consistencia, dificulta auditorías y puede crear errores sutiles (“¿cuál copia es la fuente de la verdad?”). Los LLMs a veces recomiendan denormalizar como si fuera una decisión única, no una carga operacional continua.
Antes de aceptar una recomendación de LLM, exige una prueba rápida:
Si el modelo y las consultas no se alinean, la recomendación es ruido —aunque suene confiada.
Los LLMs a menudo tratan la “consistencia” como una preferencia en vez de como una restricción del producto. Eso lleva a recomendaciones que parecen razonables en el papel (“usa un almacén NoSQL escalable”) pero que se desmoronan cuando las acciones reales del usuario requieren actualizaciones atómicas multi-paso.
Muchos flujos de producto no son una sola escritura: son varias escrituras que deben ocurrir todas o ninguna.
Pagos es el ejemplo clásico: crear un cargo, marcar una factura como pagada, decrementar el saldo de la cuenta y añadir un registro de auditoría. Si algún paso falla después del primero, has creado una discrepancia que usuarios y finanzas notarán.
El inventario es similar: reservar stock, crear una orden y actualizar disponibilidad. Sin transacciones, puedes sobrevender en picos o sufrir fallos parciales.
Los LLMs a veces equiparan consistencia eventual con “la UI puede refrescarse más tarde”. Pero la pregunta es si la acción de negocio puede tolerar la divergencia.
Los conflictos en reservas muestran por qué esto importa: dos usuarios intentan reservar el mismo hueco. Si el sistema acepta a ambos y “resuelve más tarde”, no mejoras la UX: creas incidencias de soporte y devoluciones.
Incluso con una base de datos que soporte transacciones, el flujo alrededor necesita semánticas claras:
Cuando un LLM ignora esto, puede recomendar arquitecturas que requieren trabajo experto en sistemas distribuidos solo para alcanzar la corrección productiva “normal”.
Los LLMs suelen recomendar una base de datos “rápida” como si la velocidad fuera una propiedad intrínseca del motor. En la práctica, el rendimiento es la interacción entre tu carga, esquema, forma de consultas, índices, hardware y ajustes operativos.
Si no especificas qué debe ser rápido —latencia p99 para lecturas de fila única, analítica por lotes, throughput de ingestion o tiempo hasta el primer byte— un LLM puede recurrir a elecciones populares.
Dos productos pueden decir “baja latencia” y aun así tener patrones opuestos: uno es lookups key-value; el otro es búsqueda + filtrado + ordenación en muchos campos.
El consejo de rendimiento también se desvía cuando los modelos ignoran:
Un LLM puede asumir que caches te salvarán, pero las caches solo ayudan con patrones de acceso previsibles. Consultas que escanean grandes rangos, ordenan por campos no indexados o usan filtros ad-hoc pueden perder la cache y estresar disco/CPU.
Pequeños cambios en la forma de la consulta (p. ej., paginación con OFFSET vs paginación por keyset) pueden invertir los resultados de rendimiento.
En vez de fiarte de “X es más rápido que Y”, corre una prueba ligera con forma de producto:
Los benchmarks no predicen todo, pero revelan rápidamente si las suposiciones de rendimiento de un LLM coinciden con la realidad.
Los LLMs suelen optimizar el encaje en papel —modelo de datos, patrones de consulta, palabras de moda sobre escalado— mientras obvian lo que hace que una base de datos sea viable en producción: operaciones, recuperación ante fallos y la factura real mes a mes.
Una recomendación de base de datos no está completa si no responde preguntas básicas: ¿cómo haces backups consistentes? ¿qué tan rápido puedes restaurar? ¿cuál es el plan de disaster recovery entre regiones?
El consejo del LLM frecuentemente omite estos detalles, o asume que están “integrados” sin revisar la letra pequeña.
La migración es otro punto ciego. Cambiar de base de datos más adelante puede ser caro y arriesgado (cambios de esquema, escrituras duales, backfills, reescritura de consultas). Si tu producto va a evolucionar, “fácil para empezar” no basta: necesitas una ruta de migración realista.
Los equipos no solo necesitan una base de datos: necesitan operarla.
Si la recomendación ignora logs de consultas lentas, métricas, dashboards, hooks de tracing y alertas, es posible que no notes problemas hasta que los usuarios se quejen. Las herramientas operativas varían mucho entre ofertas gestionadas y autogestionadas, y entre proveedores.
Los LLMs tienden a subestimar el coste al centrarse en el tamaño de instancia y olvidar multiplicadores:
Una base de datos “mejor” que tu equipo no puede operar con confianza rara vez es la mejor. Las recomendaciones deben alinearse con habilidades del equipo, expectativas de soporte y requisitos de cumplimiento —de lo contrario el riesgo operativo se vuelve el coste dominante.
Los LLMs a veces intentan “solucionarlo todo” proponiendo un stack como: Postgres para transacciones, Redis para cache, Elasticsearch para búsqueda, Kafka + ClickHouse para analítica, más una base gráfica “por si acaso”. Esto puede sonar impresionante, pero con frecuencia es un diseño prematuro que genera más trabajo que valor —especialmente en etapas tempranas.
Los diseños multi-base dan la sensación de coberturar riesgos: cada herramienta es “la mejor” en algo. El coste oculto es que cada datastore extra añade despliegue, monitorización, backups, migraciones, control de accesos, respuesta a incidentes y nuevos modos de fallo.
Los equipos acaban manteniendo plomería en vez de lanzar funcionalidades de producto.
Un segundo (o tercer) almacén suele justificarse cuando hay una necesidad clara y medida que la base de datos primaria no puede satisfacer sin dolor inaceptable, por ejemplo:
Si no puedes nombrar la consulta específica, el objetivo de latencia, la restricción de coste o el riesgo operativo que impulsa la división, probablemente sea prematuro.
Una vez que los datos viven en varios lugares, afrontas preguntas complejas: ¿qué store es la fuente de verdad? ¿cómo mantienes registros consistentes durante reintentos, fallos parciales y backfills?
Los datos duplicados también significan bugs duplicados —resultados de búsqueda obsoletos, recuentos de usuarios inconsistentes y reuniones de “depende del dashboard que mires”.
Empieza con una base de datos generalista que cubra transacciones y reporting. Añade un almacén específico solo después de poder (1) demostrar que el sistema actual falla frente a un requisito y (2) definir un modelo de propiedad para sincronía, consistencia y recuperación.
Mantén la vía de escape, no la complejidad.
Los LLMs pueden ser útiles para generar un primer borrador de recomendación de base de datos, pero debes tratarlo como una hipótesis. Usa la lista de verificación siguiente para validar (o rechazar) la sugerencia antes de comprometer tiempo de ingeniería.
Convierte el prompt en requisitos explícitos. Si no puedes redactarlo con claridad, el modelo probablemente adivinó.
Boceta las entidades y relaciones reales (aunque sea un esquema). Luego lista tus patrones de acceso y consultas principales.
Traduce “debe ser rápido y fiable” en pruebas medibles.
Usa formas de datos y mezclas de consultas realistas, no ejemplos de juguete. Carga un dataset representativo, ejecuta consultas bajo carga y mide.
Si el LLM propuso varias bases de datos, prueba primero la opción monolítica más simple y demuestra por qué repartir es necesario.
Si quieres acelerar este paso, una aproximación práctica es prototipar el fragmento de producto que impulsa la decisión de base de datos (un par de entidades clave + endpoints principales + las consultas más importantes). Plataformas como Koder pueden ayudar aquí: describes el flujo en chat, generas una app web/backend funcional (comúnmente React + Go + PostgreSQL) e iteras rápido mientras afinas esquema, índices y forma de consultas. Funcionalidades como modo de planificación, snapshots y rollback son especialmente útiles cuando experimentas con modelos de datos y migraciones.
Escribe una breve justificación: por qué esta base de datos encaja con la carga, qué compromisos aceptas y qué métricas forzarían una reevaluación posterior (p. ej., crecimiento sostenido de escrituras, nuevos tipos de consulta, requisitos multi-región, umbrales de coste).
Trátalo como una hipótesis y una forma de acelerar la generación de ideas. Úsalo para sacar a la luz compensaciones, requisitos que faltan y una lista corta inicial; luego valídalo con tu equipo, las restricciones reales y una prueba de concepto rápida.
Porque tu prompt suele carecer de restricciones sólidas. El modelo a menudo:
Pídele que liste explícitamente sus suposiciones antes de nombrar cualquier base de datos.
Proporciona números y ejemplos, no adjetivos:
Si no puedes especificar esto, la recomendación será en gran medida una conjetura.
Úsalo para generar una lista de requisitos y opciones candidatas, y luego exige una comprobación de esquema y consultas:
“Escala” no es un tipo de base de datos; es lo que estás escalando.
Muchas apps alcanzan límites por:
Un sistema relacional bien diseñado puede escalar mucho antes de que cambiar de base de datos sea la solución correcta.
Suelen estar subespecificadas en las recomendaciones.
Si tu producto necesita actualizaciones multi-paso que deben triunfar o fallar en conjunto (pagos, inventario, reservas), necesitas soporte claro para:
Si un LLM no pregunta sobre esto, exige aclaraciones antes de adoptar su sugerencia.
Porque las relaciones entre datos definen la complejidad de las consultas.
Si con frecuencia necesitas consultas entre entidades (filtros, joins, agregaciones sobre muchos atributos), un modelo documental puede obligarte a:
Eso incrementa la amplificación de escrituras, el riesgo de inconsistencia y la complejidad operacional.
El rendimiento depende de tu carga de trabajo, esquema, índices y concurrencia, no solo del nombre.
Realiza una prueba pequeña y con forma de producto:
Cada datastore extra multiplica la superficie operacional:
Empieza con una base de datos generalista para la carga principal. Añade otra solo cuando puedas señalar un requisito medido que la primera no puede satisfacer.
Pide un modelo de coste que incluya los multiplicadores reales:
Además, requiere un plan operativo: pasos de backup/restore, objetivos RPO/RTO y cómo detectar consultas lentas y problemas de capacidad.
