We use Google Cloud SQL with MySQL instances as our primary data storage for all our applications. Performance is great and configuring secure environments is straightforward. We reduced our DB maintenance tasks by 75% and our systems are running better than ever. Automatic backup policies and high availability replication are 1 click away.
Pros
Configuring a high availability cluster of MySQL or PostgreSQL databases is as easy as choosing how many instances do you want to have. Read-only replicas of the master DB can also be used for read operations relying on the "almost instant" replication mechanisms available.
Plays really well with other Google Cloud products, so interoperation with Cloud Functions, Cloud Run, Compute Engine, AppEngine, Kubernetes, VPC, etc. is straightforward and easy to secure, isolating the systems from outside.
Uptime SLA is high and maintenance operations are planned and notified in anticipation. Network and CPU performance is really good.
Automatic failover on high availability setups will automatically promote a read replica to master almost transparently for the client, so our applications will keep running even if the master DB server crashes.
Cons
There are no multi-master replication options. That may be a problem on distributed, high load, high performance environments.
Not many DB vendors available. MySQL came first, PostgreSQL took longer to be available and just now SQL Server is being offered as Beta.
Can get pricey quickly if you need to grow fast and much.
Likelihood to Recommend
For any serious production setup, where "serious" means aware of the importance of having automatic/secure backups, a good recovery plan, high availability options and managed DB server maintenance, I go with this solution before any self-managed option.
I'd be cautious if I need too much processing power or storage available for my DB. On these cases, I'd first think again about my selected DB architecture, and then analyze some options to calculate ROI of each investment.
