El principio del módulo de datos de AWS es la mitad del trabajo y ya está hecho: cada tipo de dato en el almacén cuya forma de acceso coincide con la suya, los objetos gordos con puntero, el historial como honeypot con TTL y PII resueltos el día uno. Queda traducir las casas — y conocer a la vecina que AWS no tenía tan protagonista.

Dato del agente	En AWS	En GCP
Sesiones / estado por clave	DynamoDB	Firestore (documentos + TTL)
Negocio relacional	Aurora / RDS	Cloud SQL (o AlloyDB) PostgreSQL
Vectores	pgvector / OpenSearch / S3 Vectors	pgvector / Vertex AI Vector Search
Objetos	S3	Cloud Storage (GCS)
Caché caliente	ElastiCache (Redis)	Memorystore (Redis)
Analítica sobre historia	(Athena/Redshift, secundarios)	BigQuery (protagonista)

La tesis del módulo

Tres traducciones son directas — GCS es S3, Memorystore es ElastiCache, Cloud SQL es RDS — y dos piezas piden pensar de nuevo: Firestore guarda documentos consultables (no solo valores por clave), lo que absorbe casos que en AWS repartías, y BigQuery es un almacén analítico tan barato de usar que cambia la respuesta a “¿dónde viven los datos fríos de la plataforma?”. El reparto por forma de acceso no cambió; cambió qué tan lejos llega cada casa.

Firestore: la sesión con estructura

Firestore es la base administrada de documentos (jerarquías de colecciones con campos consultables), serverless y con TTL nativo. Cubre el rol exacto de DynamoDB en la plataforma — sesiones e historial por clave, latencia baja, escala automática — con una diferencia de modelo a favor: los documentos se consultan por campos sin diseñar índices de acceso por adelantado con la severidad que DynamoDB exige. “Todas las sesiones del agente X con escalada a humano esta semana” es una consulta normal, no un rediseño de tabla. El precio de esa comodidad: menos control fino del rendimiento extremo — irrelevante a la escala de una plataforma de agentes típica, relevante si procesas millones de operaciones por segundo (no es tu caso; y si lo fuera, Bigtable existe).

Las tres decisiones del honeypot — PII enmascarada antes de persistir, TTL como política de retención, acceso mínimo por service account — se toman idénticas. El argumento vive en el curso de AWS; la implementación aquí es un binding y una regla de TTL.

La decisión vectorial, versión GCP

pgvector en Cloud SQL / AlloyDB: el punto de partida sano, con el mismo argumento de AWS — si ya tienes PostgreSQL (lo tienes: fila relacional), cero piezas nuevas para volumen moderado. AlloyDB (el PostgreSQL vitaminado de Google) además lo acelera con índices columnar propios si el volumen crece.
Vertex AI Vector Search: el índice vectorial dedicado, administrado, de baja latencia a gran escala — el papel que OpenSearch jugaba en AWS, nativo del ecosistema Vertex (el RAG administrado del módulo 9 puede usarlo por debajo). Se gradúa hacia él con métricas, no con miedo — la regla no cambió.
BigQuery con vectores: para búsqueda semántica analítica (sobre corpus enormes, sin latencia interactiva), BigQuery también indexa vectores — el primo del S3 Vectors de AWS: barato, masivo, no para el camino caliente.

BigQuery: la vecina que cambia el plano

En AWS, la analítica era una nota al pie de la plataforma de agentes; en GCP merece sección, porque BigQuery — SQL serverless sobre datos masivos, pagando por consulta — está integrado con todo y cambia dos respuestas:

¿Dónde viven los datos fríos? El historial vencido del TTL, los logs de largo plazo, los resultados de cada corrida del agente: exportados a BigQuery quedan consultables por SQL a costo de bodega. La arqueología de “¿cómo se comportó el agente en los últimos 6 meses?” pasa de proyecto de ingeniería a consulta de un párrafo.
¿Sobre qué se analiza la operación? El módulo 8 lo usará como pieza central del FinOps (la facturación se exporta ahí) y el 11 para el análisis de métricas históricas. En GCP, la respuesta a “¿y esto dónde lo cruzo?” es casi siempre BigQuery.

Ojo — BigQuery no es una base operacional: su modelo (consultas analíticas por escaneo, latencia de segundos) es el opuesto del camino caliente del agente. Sesión en Firestore, negocio en Cloud SQL, análisis en BigQuery — meter la lectura de sesión del agente en BigQuery porque “ya está todo ahí” es el error de forma de acceso clásico, versión GCP. El flujo sano es unidireccional: lo operacional exporta hacia BigQuery; nunca sirve desde él.

     EL MAPA DE DATOS DE LA PLATAFORMA (GCP)

            ┌─────────────┐
            │   agente    │
            └──────┬──────┘
                   │ camino caliente
     ┌─────────┬───┴──────┬──────────┐
     ▼         ▼          ▼          ▼
 ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
 │Firestor│ │CloudSQL│ │Memoryst│ │  GCS   │
 │sesiones│ │negocio+│ │ caché  │ │objetos │
 │ (+TTL) │ │pgvector│ │caliente│ │baratos │
 └───┬────┘ └───┬────┘ └────────┘ └───┬────┘
     │          │    exportan         │
     └──────────┴─────────┬───────────┘
                          ▼
                   ┌────────────┐
                   │  BigQuery  │  frío,
                   │ (analítica)│  SQL barato
                   └────────────┘

Errores comunes

Diseñar Firestore como si fuera DynamoDB. Modelar todo por clave compuesta y renunciar a consultas es cargar la severidad de DynamoDB donde no aplica. Documentos con campos consultables — úsalo como lo que es.
Servir el camino caliente desde BigQuery. Latencia analítica en la ruta del agente. El flujo es exportar hacia, jamás servir desde.
Saltar a Vector Search por reflejo. El mismo error que saltar a OpenSearch en AWS: pgvector primero si ya hay Postgres, graduación con métricas en mano.
Objetos en la base. El PDF va a GCS; Firestore y Cloud SQL guardan el puntero. Sin cambios de nube en esta regla, ni los habrá.
Historial sin TTL “porque BigQuery es barato”. Barato de almacenar no es gratis de retener: la política de retención es de privacidad y riesgo, no de costo. El TTL se define igual, y lo exportado a BigQuery también tiene fecha de expiración escrita.

La frase para llevarse

“Tres casas se traducen solas y dos piden cabeza: Firestore te da sesiones con estructura consultable, y BigQuery te da la historia entera en SQL barato — siempre que respetes la dirección del flujo: lo operacional exporta hacia la analítica, nunca se sirve desde ella.”

Qué viene

Módulo 7: el LLM gateway y Vertex AI. El razonamiento del gateway ya está hecho — punto único, routing, fallback, y el árbol de decisión del proxy propio. Toca poblarlo con Vertex: el Model Garden con más de 200 modelos (Gemini, Claude, Llama y compañía), la pregunta de si Vertex ES el gateway, y las palancas de precio (batch, caching de contexto, throughput aprovisionado) que la economía del caso ya sabe evaluar.

Arquitectura GCP — Módulo 6: estado y datos del agente