[Jinwoo-H]

	Files	Added	Deleted	Net
Test	0	0	0	0
Prod	1	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​5	0	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​5

ELI5

This PR turns on the relay's own database server in production. Merging it changes nothing until someone runs the targeted Terraform apply below, and that apply needs Jinwoo's go (step G2).

What Changed

• production.tfvars gets three lines:
  • relay_dedicated_database_enabled = true
  • edition ENTERPRISE
  • tier db-custom-4-15360, which is 4 vCPU and 15 GB, HA.
• Enterprise Plus, the edition the design asked for, had no capacity in any us-central1 zone or shape when tried in staging on 10-16.
• What users see: nothing. A new, empty instance doesn't touch the shared auth database, sign-in, or the relay, until the move tool writes the pointer at G4 and later.

G2 create path

terraform apply \
  -target=google_sql_database_instance.relay_dedicated \
  -target=google_sql_database.relay_dedicated \
  -target=google_sql_user.relay_dedicated \
  -target=google_sql_user.relay_move_dedicated

• The read-only plan on 10-16 showed 6 to add, 0 to change, 0 to destroy:
  • the instance;
  • the orca_relay database;
  • two users on the new instance;
  • two random passwords.
• Nothing in that set touches orca-cloud-auth-db.
• The secrets, IAM, the orca_relay_move login on the shared instance, and the move job's identity come later at G3. That's 21 more adds.

Why

These are the safety notes for running the apply:

• A failed create leaves a FAILED instance whose name stays reserved for about a week. Don't delete it without first setting relay_dedicated_database_name to the next name.
• Prod has no onorca-cloud-relay-control bucket that I can see. Terraform would try to create it at G3, and the cutover's pointer lives there. Settle that before G3.

Testing

• I ran a read-only terraform plan against production state with -lock=false -refresh=false, plus a full staging rehearsal (see feat(relay-infra): the relay's own Cloud SQL instance and move-job identity (step 4, staging only) #29564).
• Automated tests added/updated, or explained why not below: this is a configuration-only change.

Review

• Stacked on feat(relay-infra): the relay's own Cloud SQL instance and move-job identity (step 4, staging only) #29564.
• Don't merge or apply without Jinwoo's go.

[OrcaWin]

Closing this public-repository configuration PR because #31792 (307f0cd) moved production Terraform and deployment operations into the private stablyai/orca-cloud repository.

I reviewed the complete five-line tfvars change and its G2 approval/apply instructions. cloud/infra/terraform/environments/production.tfvars no longer exists in current Orca main, and cloud/README.md explicitly assigns Terraform/backend/operator configuration to the private repository. Rebasing these enablement flags here would recreate retired public configuration rather than change the active production plan. Any remaining dedicated-database provisioning decision, Jinwoo approval, and targeted apply belong in the private operations repo. This closure does not claim the production instance was created or the G2 approval granted; neither is verified by this account.