1. Idempotency. Accidentally run an INSERT twice and you get two VMs instead of one. Sure you could be careful and do upsert-queries but is everyone in your org equally careful?
2. Reverts, in terraform it's as easy as removing the resource and re-applying. Or even just run teardown. Even if you've added other things in the meantime. With SQL if you've INSERTED something you need to come up with the corresponding DELETE query. Rollbacks might be a thing but can they be applied partially?
3. Version control and code reviews. And are you sure the code that was reviewed is what was actually ran in your terminal before you commited, or did you depend on manually inserted side-effects?
4. Dependencies between resources, this has already been covered a lot in this thread. Especially together with teardowns this becomes extra complicated.
1. Use a unique key check that will fail if there's already a VM with the given key.
2. The OP mentioned that you can snapshot the database and restore it to a known-good state if anything goes wrong. State databases are probably not going to be humongous in size–you can imagine snapshotting them hourly for quite a long time.
3. How do you solve this problem today? By running Terraform applies locally on your machine to test out the modifications and then approving the PR?
4. That's exactly where foreign keys come in, they are exactly what enforces correct handling of dependencies between resources. E.g. some time ago one of our PagerDuty service monitors was renamed in Terraform. The plan destroyed the old monitor and created a new one with the new name, losing the linkage to the old incidents and making it look like the service had no incidents. Now imagine modelling this relationship in IaSQL and failing to destroy the old monitor because of the incidents.
I guess the point though is all of these things are problems anyways with a programmatic interface like boto. SQL has battle-tested techniques extracted to composable common libraries that will build these safeties on top of SQL itself. So if there's an expectation that cloudSQL is a replacement for something like kubernetes, nomad, rancher, I think that's not quite the right level of abstraction -- as I see it cloudSQL is a replacement for boto.
Also not clear on how/why this would be a SaaS product - this seems like it's a library you would download, throw some keys at, and thanks.