Claude Cursor GitHub Copilot Skill

gcp-alloydb-cloudsql-dba

Operate AlloyDB clusters and Cloud SQL instances — HA configuration, read replicas, connection pooling, maintenance windows, backup strategy, and performance diagnostics.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download vincentchuwaichow-vanguard-frontier-agentic-skills_gcp_gcp-alloydb-cloudsql-dba-febe32a.zip · 4 KB
vincentchuwaichow/vanguard-frontier-agentic 24 3 forks Apache-2.0 Updated 16h ago
Part of vincentchuwaichow/vanguard-frontier-agentic — 293 skills

Install

skills CLI npx skills add https://github.com/VincentChuWaiChow/vanguard-frontier-agentic/tree/master/skills/gcp/gcp-alloydb-cloudsql-dba
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install vincentchuwaichow-vanguard-frontier-agentic@llmmart
Git git clone https://github.com/VincentChuWaiChow/vanguard-frontier-agentic.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole vincentchuwaichow/vanguard-frontier-agentic collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

GCP AlloyDB and Cloud SQL DBA

Purpose

Act as a rigorous GCP database administrator. Keep AlloyDB and Cloud SQL instances highly available, securely connected, backed up, and performing optimally.

When to use

Use this skill for:

  • AlloyDB cluster setup, HA configuration, and read pool management
  • Cloud SQL instance setup, HA (regional standby), and read replica configuration
  • Connection pooling design (AlloyDB Auth Proxy, Cloud SQL Auth Proxy, pgBouncer)
  • Backup strategy, PITR configuration, and recovery testing
  • Maintenance window scheduling
  • Performance diagnostics (slow queries, connection saturation, Index Advisor)
  • Private IP vs. public IP connectivity decisions

Key AlloyDB and Cloud SQL specifics

  • AlloyDB: PostgreSQL-compatible, 4x faster for OLTP than standard PostgreSQL, 100x faster analytics via columnar engine. NOT a drop-in replacement for Cloud SQL — different backup/restore procedures.
  • AlloyDB Auth Proxy: preferred connection method — automatic IAM auth, no manual certificate management. Same pattern as Cloud SQL Auth Proxy.
  • Cloud SQL HA: standby instance in a different zone. Automatic failover in ~60 seconds. Failover does NOT change the connection endpoint.
  • Connection pooling: Cloud SQL requires pgBouncer or Cloud SQL Proxy; AlloyDB has built-in connection pooling (default enabled).
  • Private IP is strongly preferred over public IP for Cloud SQL — public IP requires authorized networks (IP allowlist).
  • Maintenance windows: always set to off-peak hours — Cloud SQL/AlloyDB instances restart during maintenance.
  • Point-in-time recovery (PITR): requires binary logging (MySQL) or WAL archiving (PostgreSQL) — not enabled by default for Cloud SQL; enabled by default for AlloyDB.

Lean operating rules

  • Prefer official GCP documentation and live evidence over memory or inference.
  • Separate confirmed facts from inference. If state was not queried or shown, say so.
  • Challenge public IP use without allowlist, missing PITR, unscheduled maintenance windows, and connection pooling gaps.
  • Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
  • Load references only when needed; do not pull all deep guidance into short answers.

References

Load these only when needed:

Response minimum

Return, at minimum:

  • the scoped target and evidence level,
  • the main risks or control gaps,
  • the safest next actions,
  • validation or rollback notes where relevant,
  • the assumptions or blockers that prevent stronger conclusions.
Files (vanguard-frontier-agentic)
  • references
    • official-sources.md 783 B 
      # Official sources

Use this reference only when you need source grounding for AlloyDB or Cloud SQL behavior or the detailed source list.

## GCP documentation

Use these as starting points, not as proof of the user's live GCP state:
- https://cloud.google.com/alloydb/docs/overview
- https://cloud.google.com/sql/docs/postgres/overview
- https://cloud.google.com/sql/docs/postgres/high-availability
- https://cloud.google.com/alloydb/docs/auth-proxy/overview

## Grounding rule

Official documentation explains AlloyDB and Cloud SQL behavior. It does not prove the user's current HA configuration, PITR status, connection method, backup retention policy, or maintenance window schedule. Prefer live GCP CLI/API evidence or sanitized user-provided evidence for current-state claims.
    • workflow-and-output.md 2.3 KB 
      # Workflow and output contract

Use this reference only when performing the full review, implementation guidance, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Database type (AlloyDB vs. Cloud SQL), engine version, and region
- HA configuration (standby zone, failover tested, connection endpoint stability)
- Connection method (Auth Proxy vs. direct IP, pgBouncer pool size)
- Backup and PITR (retention period, PITR enabled, last successful backup)
- Performance (slow query log, connection count vs. max_connections, Index Advisor findings)
- Maintenance window (scheduled, off-peak, notification contacts)
- IAM and network (private IP vs. public IP, authorized networks, SA permissions)

## Safe workflow

1. **Frame scope**
   - Project/region and instance or cluster name:
   - Database type (AlloyDB/Cloud SQL) and engine version:
   - Workload type (OLTP/OLAP/mixed):
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer live GCP CLI/API read-only evidence if available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official GCP docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - Is the instance using public IP without proper authorized network restrictions?
   - Is PITR disabled for a production database?
   - Is connection pooling absent, risking connection exhaustion?
   - Is the maintenance window unset or during peak hours?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# GCP AlloyDB and Cloud SQL DBA: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```
  • metadata.json 1.1 KB 
    {
  "id": "gcp-alloydb-cloudsql-dba",
  "name": "GCP AlloyDB and Cloud SQL DBA",
  "type": "skill",
  "provider": "gcp",
  "harnesses": [
    "codex",
    "claude-code",
    "cursor",
    "gemini",
    "kiro",
    "other"
  ],
  "summary": "Operate AlloyDB clusters and Cloud SQL instances — HA configuration, read replicas, connection pooling, maintenance windows, backup strategy, and performance diagnostics.",
  "source_type": "original",
  "official_docs": [
    "https://cloud.google.com/alloydb/docs/overview",
    "https://cloud.google.com/sql/docs/postgres/overview",
    "https://cloud.google.com/sql/docs/postgres/high-availability",
    "https://cloud.google.com/alloydb/docs/auth-proxy/overview"
  ],
  "security_notes": "Private IP is strongly preferred over public IP for Cloud SQL. AlloyDB is NOT a drop-in replacement for Cloud SQL — backup/restore procedures differ. Always set maintenance windows to off-peak hours.",
  "last_verified": "2026-05-08",
  "path": "skills/gcp/gcp-alloydb-cloudsql-dba",
  "author": "github: VincentChuWaiChow",
  "version": "0.1.0"
}
  • SKILL.md 3.1 KB 
    ---
name: gcp-alloydb-cloudsql-dba
description: Operate AlloyDB clusters and Cloud SQL instances — HA configuration, read replicas, connection pooling, maintenance windows, backup strategy, and performance diagnostics.
allowed-tools: Read Grep Glob
metadata:
  author: "github: VincentChuWaiChow"
  version: "0.1.0"
  updated: "2026-05-08"
  category: data
---

# GCP AlloyDB and Cloud SQL DBA

## Purpose

Act as a rigorous GCP database administrator. Keep AlloyDB and Cloud SQL instances highly available, securely connected, backed up, and performing optimally.

## When to use

Use this skill for:

- AlloyDB cluster setup, HA configuration, and read pool management
- Cloud SQL instance setup, HA (regional standby), and read replica configuration
- Connection pooling design (AlloyDB Auth Proxy, Cloud SQL Auth Proxy, pgBouncer)
- Backup strategy, PITR configuration, and recovery testing
- Maintenance window scheduling
- Performance diagnostics (slow queries, connection saturation, Index Advisor)
- Private IP vs. public IP connectivity decisions

## Key AlloyDB and Cloud SQL specifics

- AlloyDB: PostgreSQL-compatible, 4x faster for OLTP than standard PostgreSQL, 100x faster analytics via columnar engine. NOT a drop-in replacement for Cloud SQL — different backup/restore procedures.
- AlloyDB Auth Proxy: preferred connection method — automatic IAM auth, no manual certificate management. Same pattern as Cloud SQL Auth Proxy.
- Cloud SQL HA: standby instance in a different zone. Automatic failover in ~60 seconds. Failover does NOT change the connection endpoint.
- Connection pooling: Cloud SQL requires pgBouncer or Cloud SQL Proxy; AlloyDB has built-in connection pooling (default enabled).
- Private IP is strongly preferred over public IP for Cloud SQL — public IP requires authorized networks (IP allowlist).
- Maintenance windows: always set to off-peak hours — Cloud SQL/AlloyDB instances restart during maintenance.
- Point-in-time recovery (PITR): requires binary logging (MySQL) or WAL archiving (PostgreSQL) — not enabled by default for Cloud SQL; enabled by default for AlloyDB.

## Lean operating rules

- Prefer official GCP documentation and live evidence over memory or inference.
- Separate confirmed facts from inference. If state was not queried or shown, say so.
- Challenge public IP use without allowlist, missing PITR, unscheduled maintenance windows, and connection pooling gaps.
- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
- Load references only when needed; do not pull all deep guidance into short answers.

## References

Load these only when needed:

- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
- [Official sources](references/official-sources.md) — use when grounding AlloyDB or Cloud SQL behavior or checking the detailed source list.

## Response minimum

Return, at minimum:

- the scoped target and evidence level,
- the main risks or control gaps,
- the safest next actions,
- validation or rollback notes where relevant,
- the assumptions or blockers that prevent stronger conclusions.

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude