Cada revisión de arquitectura para un proyecto de IA de agentes termina con la misma pregunta: ¿la pila que ya tenemos puede soportar lo que estamos a punto de construir? Resulta tentador responder a esta pregunta comparando el rendimiento de las bases de datos vectoriales. La cuestión más profunda es si su arquitectura puede responder a preguntas sobre datos y significado en una misma query, con las mismas garantías.

Eso es lo que un agente realmente necesita. Es la parte de la pila que la mayoría de los equipos colocan en último lugar, después de que el resto del sistema ya haya tomado forma. La base de datos operativa se subestima. Según Harvard Business Review Analytic Services, solo el 15 % de las empresas consideran que su base de datos está lista para adoptar la IA de agentes. El resultado es una arquitectura dividida que parece razonable en una pizarra y empieza a desmoronarse en producción.

Si somos honestos, vale la pena comparar los dos patrones:

• Arquitectura unificada: una sola plataforma gestiona juntos los datos operativos y la búsqueda vectorial.
• Arquitectura dividida: un almacén de vectores dedicado (Pinecone, Weaviate o un motor de búsqueda como Elasticsearch) se encuentra junto a la base de datos operativa, con un pipeline ETL que mantiene los dos sincronizados.

Deconstruyendo el ciclo viral de la migración de Postgres

Cada pocos meses, una entrada de blog muy conocida se vuelve viral en todo el ecosistema de desarrolladores: "Por qué volvimos a Postgres". Casi al instante, los hilos de comentarios se llenan con los mismos puntos previsibles: MongoDB no escala, no hay joins y la transacción es débil. Tim Carter Clausen, que escribe como The Decipherist y lleva una década ejecutando MongoDB en producción, aborda cada crítica directamente, con datos de producción reales detrás de él.

La elección de una base de datos con un modelo de datos que se adapte al resto de la pila garantiza que su velocidad de desarrollo no se vea obstaculizada por las limitaciones arquitectónicas.

Análisis profundo: El costo del impuesto de traducción de SQL

Una solicitud SQL típica realiza ocho cambios de formato en un solo viaje de ida y vuelta:

1. El cliente envía JSON.
2. La API lo convierte en un objeto JavaScript.
3. Una herramienta de ORM descompone ese objeto en filas dispersas en las tablas normalizadas.
4. La base de datos hace su trabajo.
5. Las filas se vuelven a ensamblar.
6. Se asignan de nuevo a un objeto.
7. El objeto se serializa de nuevo a JSON.
8. Se envía la respuesta.

El equivalente de MongoDB son cuatro transformaciones, y Clausen sostiene que llamarlas cuatro es exagerar porque la forma de los datos en realidad nunca cambia. Cada cambio de formato en la ruta de acceso de SQL consume CPU y memoria, introduce latencia y ofrece un lugar para ocultar un error.

La realidad de las actualizaciones de esquema

Cambiar el nombre de un campo, añadir un objeto anidado o reestructurar un documento ocurre en tiempo real en MongoDB sin interrupciones. La misma operación en una tabla relacional de gran tamaño puede bloquear las escrituras durante minutos o incluso horas. Para equipos con envíos semanales, la diferencia no es teórica. Es la diferencia entre añadir un campo esta tarde y planificar un periodo de mantenimiento para el siguiente trimestre.

El impuesto latente en la capa de indexación

La misma divergencia arquitectónica aparece en la capa de indexación. Consideremos una query con la que está familiarizado cualquiera que gestione un sistema operativo: mostrar los últimos 10 pedidos de un producto determinado en un país determinado.

• En el modelo orientado a documentos: un único índice compuesto cumple esta función directamente, incluyendo los campos anidados dentro de los arreglos.
• En un sistema relacional (JSONB): el equivalente suele requerir un índice GIN para el contenido del arreglo, un índice B-tree independiente para los campos escalares y una ordenación intensiva que el planificador de query no puede evitar. El plan lee más filas de las necesarias, lo que dificulta su escalado a medida que aumentan los datos. Nada de esto es visible desde la capa de aplicación, pero todo es visible en su factura de la nube.

El poder estructural de la localidad de los datos

La perspectiva estructural que subyace a ambos puntos es la localidad de los datos. En el modelo orientado a documentos, el modelo lógico y el modelo físico son idénticos. La forma que escribe la aplicación es la forma exacta que almacena la base de datos, y la forma que almacena la base de datos es la forma exacta que la capa de recuperación devuelve a un agente de IA. Esta equivalencia elimina por completo los pipeline de sincronización, la lógica de guardar doble y las complejas tareas de conciliación que, de otro modo, las arquitecturas fragmentadas necesitan para aproximar el mismo resultado.

Un marco de decisión de un arquitecto

El marco de decisión de Pachot se orienta hacia estas realidades técnicas:

• Elija relacional (Postgres): para una base de datos centralizada que sirva muchas aplicaciones dispares donde aún no se conocen todos los casos de uso finales.
• Elija el documento (MongoDB): para una única aplicación compilada a partir de un modelo de dominio y almacenada exactamente como la aplicación lo maneja.

La siguiente pregunta que conviene plantearse es cuál de estas opciones describe mejor el proyecto que está desarrollando en 2026: ¿microservicios con contextos delimitados, esquemas que se actualizan semanalmente o objetos de dominio almacenados tal y como los concibe de forma natural su aplicación?

“Una base de datos es buena y rápida si se usa correctamente, y lo más importante es elegir una que usted conozca o que quiera aprender.”
— Franck Pachot, AWS Data Hero & Oracle Certified Master

Vea la charla