Cloud SQL Databases & Users

Beyond the instance itself, teams need per-application databases and scoped users. zop.dev manages Cloud SQL databases and users as standalone resources so schemas and access can evolve after the instance exists.

Databases and users on instances that exist

Cloud SQL databases and users on existing instances (resource types cloud_sql_database and cloud_sql_user).

Names, credentials, and the sqladmin schema

Database name; user name and credentials; the parent cloud_sql_instance accepts the full sqladmin.DatabaseInstance schema with auto-generated passwords stored in Secret Manager.

Reachable only from the provisioner API

Available through the cloud-resource-provisioner API.

Day-2 shapes, not day-1

Instance provisioning answers day one; these two resource types answer everything after. A new application needs its own schema on the shared staging instance: cloud_sql_database. A reporting tool needs read access next quarter: cloud_sql_user. Because both are standalone resources rather than instance settings, schemas and access evolve without touching the instance, and the record of what exists lives in managed configuration instead of in the memory of whoever ran the last CREATE DATABASE.

Passwords are generated, not chosen

The credential flow is the quietly important part: passwords are auto-generated and stored in Secret Manager, so no human picks one, types one, or pastes one into a chat thread. Applications read credentials from the secret store; humans who need access get their own scoped user rather than borrowing an application’s. Rotation fits the same shape. Regenerate and update the secret, with no hunt through configs for hardcoded strings. The unglamorous discipline this enables is per-consumer users: when each application and tool has its own login, revoking one is surgery instead of an outage.

One instance, many tenants

Databases are nearly free to add. The instance’s vCPUs, memory, and storage are the bill, and another schema on an existing instance adds no line item. That economic pull toward consolidation is legitimate for dev and staging, where a dozen schemas on one modest instance beats a dozen idle instances. The counterweight is shared fate: tenants share the same maintenance windows, the same failure domain, and the same IOPS budget, so one runaway migration slows everyone. Production databases whose load or blast radius matters earn their own instance; everything else is a candidate for the shared one.