Cloud SQL
What does zop.dev create for Cloud SQL?
zop.dev provisions a Cloud SQL instance with its network configuration, backups and credentials. Cloud SQL stops differently from other databases: stopping is a patch to the instance activation policy, and storage plus any read replicas keep billing while it is stopped.
| Field | Value |
|---|---|
| Cloud | gcp |
Cloud SQL is Google’s managed MySQL and PostgreSQL service. zop.dev provisions the instance with SSL, secrets, schemas, and access roles configured, so applications get a connection string rather than a to-do list.
An instance, replicas, secrets, and db-init jobs
Cloud SQL instance plus optional read replicas, database, user, two SSL certificates, firewall rules, seven Secret Manager secrets, and Kubernetes db-init jobs that create schemas.
Engine, tier, disk, and availability settings
sql_type and sql_version (app defaults MYSQL_8_0 / POSTGRES_14); machine_type default db-f1-micro; disk_size 10 GB; disk_type PD_SSD|PD_HDD with disk_autoresize; availability_type ZONAL|REGIONAL (default ZONAL); activation_policy ALWAYS; read_replica with num_read_replicas and zones; deletion_protection true; require_ssl; authorized_networks[]; db_collation; sql_edition ENTERPRISE|ENTERPRISE_PLUS; multi_ds and databases[].Machine tiers come from a live GCP lookup
GCP SQL machine tiers are fetched live rather than from a static catalog. The provisioner API adds cloud_sql_database and cloud_sql_user as separate resource types.
Stopping is an activation policy change
There is no stop API on Cloud SQL. Stopping an instance means patching its activationPolicy
from ALWAYS to NEVER, which is why the permission needed is cloudsql.instances.update
rather than anything named stop.
That matters for schedules: the operation looks like a configuration change in audit logs, not a lifecycle event, and tooling that watches for stop events will not see it.
What keeps billing while stopped
Compute stops. Storage does not, and neither do backups. A stopped instance with 500 GB provisioned continues to bill for that storage at the full rate.
Read replicas are the bigger surprise: a replica does not stop when its primary does. It keeps running and keeps billing, which means stopping a primary without handling its replicas saves substantially less than expected.
Storage grows automatically and never shrinks
Automatic storage increase is on by default and is the right setting, because running out of disk on a database is worse than paying for headroom. But the increase is permanent. Cloud SQL cannot shrink allocated storage, so a one-off import that doubles the disk leaves a doubled storage bill forever.
The only way back is export, recreate, import.
High availability doubles compute
HA runs a standby in a second zone, and you pay for it. It is correct for production and routinely enabled on development instances by habit, where it doubles the cost to protect an environment nobody would page for.
Private IP is worth setting at creation
Moving an instance from public to private IP later requires downtime and network reconfiguration. Setting it at provisioning time costs nothing and removes the instance from the public internet entirely.