ADR-0004: GCP — Cloud Run + Cloud SQL + Secret Manager

Status: Accepted (resolves SPEC Open Q8)
Date: 2026-05-08
Deciders: Seth (Lead Architect), Blair (CEO sign-off pending)

Context

SPEC Open Q8: hosting choice. Per arch-overview.md the architecture
deep-dive recommends GCP. Privacy counsel will ask about hosting before
GA; the ADR is the artifact.

Decision

• Compute: Cloud Run (containers, autoscale, request-timeout-friendly)
• Database: Cloud SQL Postgres 16 with pgvector extension enabled
• Secrets: Google Secret Manager (no .env in containers)
• Logging / observability: Cloud Logging → BigQuery sink for cost-per-cohort report (resolves part of SPEC Open Q11; full telemetry pick deferred)
• Region: us-central1 (single-region for V1)

Provisioning happens in Slice 1, not the kickoff. The kickoff locks the
choice so Slice 1’s deploy work doesn’t re-litigate it.

Consequences

Positive:

• Single cloud vendor; consistent IAM model.
• Cloud Run autoscale fits the request-spiky workload (chat).
• BigQuery sink unblocks the weekly cost-per-cohort report the cost review demanded.

Negative / costs:

• Cloud SQL has no built-in pgvector tuning surface; large-scale tuning later may be cumbersome.
• Anthropic dependency + GCP dependency = two vendors on the critical path.

Mitigations:

• tenant_id partition (ADR-0003) keeps the Pinecone-migration path open.
• llm.call wrapper (ADR-0005) keeps the Anthropic-portability path open.

Alternatives considered

• AWS (ECS Fargate + RDS Postgres + Secrets Manager) — rejected: the team has more GCP experience.
• Heroku — rejected: too opinionated, weak fit for Cloud SQL-class Postgres.
• Self-hosted on a single VM — rejected: ops overhead.