[Update] That said, from what I understand, they have a road map to maintaining read replicas and queued writes. Not sure what the date on it is though.
Surely that's what HA is? no downtime as you update each node one at a time?
If it's impossible then it's a dealbreaker.
A major client of mine migrated to AWS because of this and other issues.
To be fair, we wouldn't use GCP for anything but virtual servers and storage replication... I have no desire to tie us to Google's infrastructure any more than necessary.
Were your master and standby in the same availability zone? Can't you set diff maintenance windows? WTF?
https://cloud.google.com/sql/faq#maintenancerestart
According to the link above, you can taper your upgrade windows, it looks like.
You can run PostgreSQL on a VM just fine. You just have to manage itself. Cloud SQL comes with some upsides (zero management, spectacular HA failover capabilities) and some downsides (lack of extensions, lives on a separate network, no control over maintenance window); you have to decide what you're willing to live with.
You can set the upgrade window, but it can't be predicted. What you can control is the order — e.g. set your staging instance to "early" and production instance to "late", then hopefully staging should be upgraded first and you'll know ahead of the production upgrade if any issues arose.
[1] https://cloud.google.com/compute/docs/instances/live-migrati...
indeed, this is the primary reason i wish to switch. i have no problem maintaining our own stuff, we do that anyway. :) thanks for the details.
(disclaimer: I'm one of the many authors on the paper, although for building parts of the underlying tech, not writing the prose)
We consolidated everything on GKE now which lets use use VMs but still have the kubernetes control plane looking after things for us which has been great so far.
The whole experience was so amateur and unprofessional it really soured me on GCE. They do have some cool tech but it seems like their cloud division needs to mature a bit.