Clarify Database

This fragment asks nothing. It reads the inventory, resolves what it can, assigns a disposition per row, and returns rows. clarify-assemble.md presents them.

Fire when: Database resources present (Cloud SQL, Spanner, Memorystore).

Q6 (availability, in clarify-global.md) selects RDS vs Aurora for Cloud SQL PostgreSQL/MySQL — see clarify-global.md § Q6 (the canonical availability question, shared with azure-to-aws). Q12–Q13 tune sizing and storage within the family Q6 chose. Q12–Q13 never override Q6.

Database Engine Detection

Before asking questions, detect the database engine from IaC (database_version in google_sql_database_instance). State what was found:

“I see Cloud SQL for PostgreSQL (or MySQL) in your Terraform.”

If the engine is not PostgreSQL or MySQL, note the appropriate RDS or DynamoDB target. Ask the user to confirm if detection is ambiguous.

Skip Q12/Q13/Q13b when Cloud SQL (PostgreSQL or MySQL) is not present in inventory — auto-detect from IaC; no separate screening question required.

Q12 — What does your database traffic pattern look like?

Fire when: Cloud SQL (PostgreSQL or MySQL) present in inventory. Skip when: no Cloud SQL.

Auto-extract signal (dev-tier): When all Cloud SQL instances match dev pattern (db-f1-micro, db-g1-small, or tier contains micro/small with availability_type: ZONAL), extract database_traffic: "steady" with chosen_by: "extracted" and skip Q12. When instances mix dev and prod tiers, ask Q12.

Rationale: Traffic pattern informs capacity planning on the target already chosen by Q6.

Context for user: Give concrete examples so the user can pattern-match:

• Steady, predictable load — consistent query volume day-to-day, no major spikes (e.g., internal CRUD app, content CMS)
• Read-heavy with occasional write spikes — mostly reads with bursts of writes at certain times (e.g., reporting dashboards, catalog browsing with periodic bulk imports)
• Write-heavy or globally distributed writes — high write throughput or writes coming from multiple regions (e.g., IoT ingestion, multi-region user-generated content, event logging)
• Rapidly growing — traffic is noticeably increasing month over month, doubling every few months (e.g., post-launch growth, viral product)

Understanding your database traffic pattern helps me recommend the right sizing on AWS — within the RDS or Aurora family Q6 already selected.

1. Steady, predictable load — consistent volume, no major spikes
2. Read-heavy with occasional write spikes — mostly reads, periodic write bursts
3. Write-heavy or globally distributed writes — high write throughput or multi-region writes
4. Rapidly growing — doubling every few months
5. N/A — We don’t use Cloud SQL
6. I don’t know

Interpret:

Default: 1 — database_traffic: "steady".

Q13 — What’s your typical database I/O workload?

Fire when: Cloud SQL (PostgreSQL or MySQL) present in inventory. Skip when: no Cloud SQL.

Auto-extract signal (dev-tier): Same dev-tier pattern as Q12 — extract db_io_workload: "low" with chosen_by: "extracted" and skip Q13 only when all instances are dev-tier. When instances mix dev and prod tiers, ask Q13.

Rationale: On AWS, storage and I/O billing differ between RDS and Aurora. This captures how disk-heavy the workload is. Q6 still governs RDS vs Aurora — this question only selects storage/I/O options within that family.

1. Low (< 1,000 IOPS) — Mostly reads, infrequent writes
2. Medium (1,000–10,000 IOPS) — Balanced workload
3. High (> 10,000 IOPS) — Write-heavy, high transactions
4. N/A — We don’t use Cloud SQL
5. I don’t know

Interpret:

Default: 2 — db_io_workload: "medium".

Q13b — Approximately how large is your primary database?

Fire when: Cloud SQL (PostgreSQL or MySQL) present in inventory. Skip when: no Cloud SQL, or engine is SQL Server (DMS is always recommended for SQL Server regardless of size).

Rationale: Database size is the primary driver of migration tooling selection. pg_dump/pg_restore is sufficient for small databases but becomes impractically slow above ~10GB within a typical maintenance window. pgcopydb’s parallel copy cuts migration time by 3–5x for medium databases. Very large databases (>500GB) require DMS for continuous replication regardless of whether a maintenance window exists.

Auto-detect signal: Read disk size from google_sql_database_instance: config.disk_size_gb (canonical per schema-discover-iac.md; also accept legacy config.disk_size or gcp_config.disk_size_gb). Map to Q13b band and skip Q13b when unambiguous:

Allocated ≠ actual: Terraform disk_size is allocated capacity — an upper bound on data size, not a measurement of it. Cloud SQL’s minimum allocation is 10 GB, so a nearly-empty dev database still reads as 10 GB. The extracted band is safe for tool selection (it never underestimates), but label it as allocated on the Assumption Sheet — e.g. “up to 10 GB (allocated)” — and note that the generated migration script measures actual data size before committing to a tool (see generate-artifacts-scripts.md). If the user corrects the band downward (“actually under 10GB of data”), accept it — data below the allocation is always plausible.

If multiple instances disagree, ask Q13b. Record raw GB in metadata.inventory_clarifications.db_size_gb when extracted.

Database size determines which migration tool we recommend — this directly affects your migration window length and risk.

1. < 10 GB — small, pg_dump/pg_restore completes in minutes
2. 10 GB – 100 GB — medium, pgcopydb recommended for parallel copy
3. 100 GB – 500 GB — large, pgcopydb required; plan for multi-hour window
4. 500 GB — very large, AWS DMS strongly recommended regardless of window
5. I don’t know

Interpret:

Default: 5 — design_constraints.db_size: { value: "unknown", chosen_by: "default" } (default to pgcopydb; safer than pg_dump at unknown scale).

Rows returned

availability is not here — it is resolved once in clarify-global.md (the canonical availability question) and consumed by this fragment’s engine-detection table, never re-asked or re-resolved per database category.

Who consumes these

Status — build step 5 (restructure)

Implemented. Restructured into the fragment-returns-rows pattern; no change to firing rules, defaults, or interpretation — only the presentation split (this fragment computes, clarify-assemble.md presents).