Two production deployment profiles: Profile A · Elastic-Serverless (managed containers + managed Postgres — Google runs the servers and the database) fits the bursty, seasonal nature of quote traffic (idle most of the day, spikes after a marketing push) with minimal ops; Profile B · High-Scale Transactional & Analytics (orchestrated compute (a Kubernetes cluster — GKE) + HTAP Postgres) is for sustained transactional load and heavy read fan-out. Both speak the same Postgres interface (identical SQL), so moving A→B is non-breaking — a scaling decision, not a rewrite.
Layer guide (click any term): serverless · Cloud Run · ingress · load balancer · NEG · CDN · OLTP · AlloyDB · columnar · Pub/Sub · connection pooler · Secret Manager.
| Layer | Choice | Why |
|---|---|---|
| Compute | Cloud Run (scale-to-zero: costs nothing while idle)GKE Autopilot + Cloud Run edge | lowest ops; matches bursty/seasonal quote loadhosting ML models + long-running background jobs |
| OLTP | Cloud SQL Postgres 15 (HA — high availability, PITR)AlloyDB (HTAP, columnar) | portable, cheapheavy read fan-out / operational analytics at scale |
| RAG vectors | Vertex Vector SearchAlloyDB pgvector (co-located) | managed scalevectors live beside policy rows — one database for joins + audit |
| Analytics | BigQuery (both) | actuaries build rates here; results are copied to the live database so the hot path never waits |
Rationale: this is the path actually built and operated — Cloud Run blue/green, Terraform, Workload Identity Federation, Secret Manager. The conversation moves from "here's what I ran in production" to "here's how it generalizes" — see the AWS mirror and the side-by-side.