Cómo los LLMs eligen bases de datos según las necesidades del producto — y fallan

Por qué la gente usa LLMs para elegir bases de datos

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.

Lo que “inferir a partir de las necesidades del producto” realmente significa

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:

• datos relacionales → SQL
• documentos flexibles → almacén documental
• analítica → almacén columnar
• cache → key-value store
• búsqueda de texto completo → motor de búsqueda

Ese mapeo puede ser realmente útil al principio, especialmente cuando la alternativa es una página en blanco.

Consejo frente a decisión final de arquitectura

Una recomendación de LLM se debe tratar como una hipótesis, no como un veredicto arquitectónico. Puede ayudarte a:

• nombrar las preguntas clave que hay que responder
• identificar desajustes obvios temprano
• redactar un memo de decisión que afinarás con el equipo

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.

Qué puede salir mal (y cómo bajar el riesgo)

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.

Cómo los LLMs convierten requisitos en una elección de base de datos

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.

Qué trata como entradas

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:

• la redacción y estructura de tu prompt (qué enfatizas, qué omites)
• la descripción del producto (mapea “chat”, “analítica”, “pagos”, “IoT”, etc. a arquitecturas típicas)
• restricciones declaradas (proveedor cloud, presupuesto, habilidades del equipo, plazos)
• “patrones pasados” aprendidos en sus datos de entrenamiento (stacks comunes, consejos de blogs populares, emparejamientos frecuentes)

Como muchos prompts están incompletos, el modelo a menudo rellena huecos con suposiciones implícitas —a veces correctamente, a veces no.

Qué produce como salidas

La mayoría de respuestas aterrizan en tres capas:

1. una categoría (SQL vs NoSQL; relacional vs documento vs key-value)
2. motores específicos (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)
3. un paquete de “buenas prácticas” (índices, cacheo, réplicas de lectura, sharding, event sourcing)

El resultado puede sentirse como una recomendación clara, pero a menudo es un resumen estructurado de opciones convencionales.

Por qué puede sonar seguro sin estarlo

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.

Qué incluyen realmente las “necesidades del producto"

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.

Necesidades funcionales (qué construyes)

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.

Necesidades no funcionales (cómo debe comportarse)

Las bases de datos se eligen tanto por restricciones como por características:

• objetivos de latencia (p95/p99) para acciones clave del usuario
• requisitos de disponibilidad y recuperación (¿qué downtime es aceptable?)
• mezcla lectura/escritura y picos de tráfico
• tasa de crecimiento en volumen de datos y tráfico en 6–24 meses

Un sistema que tolera unos segundos de retraso es muy distinto a uno que debe confirmar un pago en menos de 200 ms.

Necesidades operativas (lo que puedes operar)

Incluso un modelo de datos “perfecto” falla si las operaciones no encajan:

• backups y pruebas de restauración
• migraciones y evolución de esquema
• carga de on-call y staffing (experiencia DBA vs generalistas)
• límites de proveedor: cuotas del servicio gestionado, soporte regional, ventanas de mantenimiento

Necesidades reguladoras (lo que debes demostrar)

Los requisitos de cumplimiento pueden acotar opciones rápidamente:

• garantías de retención y eliminación de datos
• trails de auditoría (quién cambió qué, cuándo)
• control de acceso, cifrado y separación de funciones

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.

Dónde el razonamiento de los LLM puede desviarse de la realidad

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.

Características ≠ necesidades 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.

Las listas de comprobación pasan por alto la forma de tus datos y consultas

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:

• analítica ad-hoc en muchas dimensiones
• timelines por usuario con orden estricto
• restricciones cross-entity (por ejemplo, inventario no puede bajar de cero)

El rendimiento es un detalle de implementación, no una promesa

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.

El encaje operativo puede superar la capacidad bruta

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.

Modo de fallo 1: sobregeneralizar a partir de reglas empíricas populares

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.

El atajo clásico: “Usa NoSQL para escalar”

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:

• índices faltantes o consultas ineficientes
• retención de datos sin control
• estrategia de cache pobre
• recursos infra-provisionados

En esos casos, cambiar de base de datos no arregla la causa raíz —solo cambia las herramientas.

Lo que se ignora: joins, transacciones y corrección estricta

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:

• actualizaciones multi-paso que deben completarse o abortarse juntas (transacciones)
• corrección estricta para saldos, inventario o reservas (consistencia fuerte)
• consultas de reporting que conecten datos entre entidades (joins complejos)

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ó.

Por qué este fallo es caro

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.

Modo de fallo 2: entradas faltantes o ambiguas

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.

La trampa de “tiempo real” y “alto tráfico”

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.

Números que cambian la respuesta

Si no provees estos, el modelo los asumirá en silencio:

• QPS de lectura/escritura (pico vs promedio)
• objetivos de latencia p95/p99 (y si aplican a lecturas, escrituras o ambos)
• tamaño del dataset hoy, tasa de crecimiento, política de retención
• tamaño de los objetos (filas anchas? blobs grandes?) y cardinalidad de índices

Patrones de consulta ocultos que olvidaste mencionar

Las omisiones más dañinas suelen ser las moldeadas por consultas:

• reporting y analítica (group-bys, buckets temporales)
• filtrado/ordenación por muchos campos
• consultas ad-hoc para soporte y debugging
• backfills, reprocesos y búsquedas “muéstrame todo para el usuario X”

Una base de datos que sobresale en acceso key-value puede tener problemas cuando el producto necesita de pronto filtrado flexible y reporting fiable.

Consejo práctico: exige aclaración antes de recomendar

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.

Modo de fallo 3: desajuste del modelo de datos

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.

El desajuste suele empezar por las relaciones

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:

• simulas joins en el código de la aplicación (más viajes y complejidad), o
• denormalizas en exceso (duplicas datos entre documentos)

El coste oculto de la denormalización

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.

Prueba de cordura: esquema candidato + consultas clave

Antes de aceptar una recomendación de LLM, exige una prueba rápida:

1. Dibuja un esquema candidato (tablas/colecciones/nodos) con claves primarias y las relaciones críticas.
2. Escribe 5–10 “consultas clave” que el producto debe soportar (filtros, ordenaciones, agregaciones, búsquedas cross-entity).
3. Pregunta: ¿esta base de datos expresa esas consultas de forma natural y eficiente, sin denormalizaciones heroicas o joins multi-paso en la aplicación?

Si el modelo y las consultas no se alinean, la recomendación es ruido —aunque suene confiada.

Modo de fallo 4: puntos ciegos en transacciones y consistencia

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.

La brecha de atomicidad: actualizaciones multi-paso que deben triunfar juntas

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.

Consistencia eventual no es lo mismo que “a los usuarios no les importará”

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.

Semánticas operacionales faltantes: idempotencia, reintentos y exactamente-una-vez

Incluso con una base de datos que soporte transacciones, el flujo alrededor necesita semánticas claras:

• Claves de idempotencia para que “Pagar” clicado dos veces no cobre dos veces.
• Reintentos seguros ante fallos parciales y timeouts.
• Efectos exactamente-una-vez (o una alternativa deliberada como “al menos una vez + dedupe”) para eventos, webhooks y jobs en background.

Cuando un LLM ignora esto, puede recomendar arquitecturas que requieren trabajo experto en sistemas distribuidos solo para alcanzar la corrección productiva “normal”.

Modo de fallo 5: suposiciones de rendimiento sin pruebas

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.

“Rápido” sin contexto de carga

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.

Restricciones ocultas: índices, amplificación y particiones calientes

El consejo de rendimiento también se desvía cuando los modelos ignoran:

• Límites y compensaciones de indexado: los índices secundarios aceleran lecturas pero añaden coste y almacenamiento en escritura. Algunos sistemas tienen restricciones sobre índices compuestos, tiempo de construcción o cambios de índice online.
• Amplificación de escrituras: los motores basados en LSM pueden convertir “escrituras simples” en compactiones de fondo significativas, importante bajo ingestión sostenida.
• Particiones calientes: un diseño “sharded” puede aún embotellarse si el tráfico se concentra en un rango pequeño (p. ej., el tenant más nuevo, la fecha de hoy, un ítem muy popular).

Comportamiento de la caché y forma de la consulta

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.

Un pequeño plan de benchmarking (mejor que suposiciones)

En vez de fiarte de “X es más rápido que Y”, corre una prueba ligera con forma de producto:

1. Elige 3–5 consultas representativas (incluyendo filtros/ordenaciones en el peor caso) y 1–2 patrones de escritura (steady + burst).
2. Usa volumen de datos realista (al menos suficiente para exceder memoria; incluye skew y claves calientes).
3. Mide latencias p50/p95/p99 y throughput por separado para lecturas y escrituras.
4. Prueba variantes de índices (sin índice, índices mínimos, índices “ideales”) y registra la sobrecarga en escrituras.
5. Ejecuta con concurrencia cercana al pico esperado y observa CPU, disco, compaction y métricas de locks/transacciones.

Los benchmarks no predicen todo, pero revelan rápidamente si las suposiciones de rendimiento de un LLM coinciden con la realidad.

Modo de fallo 6: omisiones operativas y de coste

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.

El trabajo oculto: backups, recuperación y migración

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.

Observabilidad es parte del producto

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.

El coste total no es solo la tarifa por hora

Los LLMs tienden a subestimar el coste al centrarse en el tamaño de instancia y olvidar multiplicadores:

• crecimiento de almacenamiento y políticas de retención
• precios por IOPS/throughput y límites de burst
• réplicas para escala de lectura y alta disponibilidad
• tiempo de on-call, respuesta a incidentes y planes de soporte del proveedor

Alinea la base de datos con el equipo

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.

Modo de fallo 7: diseños multi-base de datos demasiado complicados

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.

Por qué falla el consejo

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.

Cuándo se justifica la persistencia poliglota

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:

• requisitos de calidad/latencia de búsqueda que superan lo que la BD principal puede ofrecer
• cargas analíticas que degradan significativamente el rendimiento transaccional
• patrones de escala que requieren modelos de almacenamiento o indexado distintos

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.

Trampas de consistencia y duplicación entre stores

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”.

Una regla práctica de decisión

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.

Una lista de verificación práctica para validar el consejo de un LLM sobre bases de datos

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.

1) Aclara las entradas (escríbelas)

Convierte el prompt en requisitos explícitos. Si no puedes redactarlo con claridad, el modelo probablemente adivinó.

• ¿Cuál es la carga central del producto: OLTP, analítica, búsqueda, series temporales, mensajería?
• Escala esperada: usuarios, escrituras/seg, lecturas/seg, crecimiento de almacenamiento, pico/medias.
• Necesidades no funcionales: uptime, multi-región, cumplimiento, presupuesto, habilidades del equipo.

2) Modela los datos y las consultas clave

Boceta las entidades y relaciones reales (aunque sea un esquema). Luego lista tus patrones de acceso y consultas principales.

• ¿Cuáles son las 10 lecturas y escrituras principales?
• ¿Qué consultas deben ser rápidas en pico?
• ¿Qué debe indexarse, juntarse, agregarse o buscarse?

3) Define tests de aceptación (criterios de éxito)

Traduce “debe ser rápido y fiable” en pruebas medibles.

• Objetivos de latencia y throughput (p95/p99) para las consultas top
• Requisitos de consistencia y transacción (¿qué debe ser atómico?)
• Casos de fallo: pérdida de nodo, particiones de red, failover regional, tiempo de backup/restore

4) Ejecuta una prueba de concepto ligera

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.

5) Documenta la decisión —y los “disparadores de cambio”

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).