Cloud SQL for PostgreSQL now generally available • Hacker News Board

Re: Cloud SQL for PostgreSQL now generally available

#71

Post by joatmon-snoo » Thu, Apr 19, 2018, 4:16 AM UTC

deesix wrote: post #42

contrahax wrote: post #23

Earlier quoted context omitted.

They don't have a great story around extensions - the ones they do have are unsupported/buggy. For example, PostGIS is missing "ST_FromGeoJSON" because it was compiled with the wrong flag - and has been this way for over a year despite hundreds of user complaints.

Disclaimer: I work on GCP Can you point me to the complaints? I will take a look.

Found it: https://groups.google.com/forum/#!topic/google-cloud-sql-dis...

Public issue tracker link: https://issuetracker.google.com/issues/37302950

Re: Cloud SQL for PostgreSQL now generally available

#72

Post by manigandham » Thu, Apr 19, 2018, 4:27 AM UTC

tinix wrote: post #37

ciguy wrote: post #9

Earlier quoted context omitted.

Unfortunately last time I used CloudSQL for MySQL it was incredibly unstable. They would take down our master AND standby at the same time for maintenance. When we filed a ticket they just said it was a known bug with no plans to fix. A major client of mine migrated to AWS because of this and other issues.

I've been thinking about moving us to Google's Cloud Platform. What I found in regards to maintenance here: https://cloud.google.com/compute/docs/regions-zones/#mainten... states that they do live migrations without any down time. Can anyone elaborate? Is this only for Compute Engine? In that case, if one can run postgres on a Compute Engine instance, why not do that instead? Surely, if one can setup a highly availab…

GCP has the best compute, storage, and networking of all the clouds. They are cheaper, faster, more scalable and more reliable than the others. Their managed services leave a lot to be desired (beta status, non-standard interfaces, and other limits) but if you're just looking to run VMs then that is the perfect fit for their cloud.

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.

Re: Cloud SQL for PostgreSQL now generally available

#73

Post by tacticus » Thu, Apr 19, 2018, 4:43 AM UTC

flamingcow wrote: post #50

pritambarhate wrote: post #19

Is point in time recovery available now in GA? I had checked it a couple of weeks ago for the beta service and it was not available. I think for a managed DB hosting point in time recovery is a critical feature.

[I'm the Cloud SQL TL] No, it isn't. We agree with you that it's an important feature for managed databases, and we're working to get it right. We decoupled it from this launch to get PostgreSQL to GA faster.

Unrelated to pg but could you badger the spanner team to make a mini spanner product :)

Related to postgres. We have many many concurrent connections but a load satisfied by an n1-standard-4 atm do you recommend a connection pooler or something to help us get down to the 100 to 200 connections we need to be at to use cloudsql?

Re: Cloud SQL for PostgreSQL now generally available

#74

Post by cellis » Thu, Apr 19, 2018, 4:54 AM UTC

I tried using this, but couldn't get the root certs to work. So I went to AWS RDS instead. A pity, it's much cheaper ( especially in beta pricing )

Re: Cloud SQL for PostgreSQL now generally available

#75

Post by litewulf » Thu, Apr 19, 2018, 5:31 AM UTC

optimusclimb wrote: post #59

Started down the path of using this when it was in beta, but had to abort when we saw there was no option to connect to it from Python App Engine Standard. Now that it's GA...it looks like that hasn't changed. Is the classic, Python, App Engine standard becoming a second class citizen? Or was there some reason why this wasn't considered GA worthy for Postgres? Trying to understand if going forward Google is trying to…

[I am a Googler and my team works on part of this]

You can connect to postgres from app engine standard... as long as its Java. See this doc https://cloud.google.com/appengine/docs/standard/java/cloud-...

And no, appengine standard is not a second class citizen. Hand-wave-ily, the connectivity path that flex uses works for postgres with minimal changes, but unfortunately some additional work is required to get appengine standard for other languages working for postgres. :(

Re: Cloud SQL for PostgreSQL now generally available

#76

Post by jordic » Thu, Apr 19, 2018, 5:34 AM UTC

theptip wrote: post #60

optimusclimb wrote: post #59

Started down the path of using this when it was in beta, but had to abort when we saw there was no option to connect to it from Python App Engine Standard. Now that it's GA...it looks like that hasn't changed. Is the classic, Python, App Engine standard becoming a second class citizen? Or was there some reason why this wasn't considered GA worthy for Postgres? Trying to understand if going forward Google is trying to…

Last I checked it wasn't possible to whitelist internal IPs (e.g. Kubernetes nodes or VM instances) to access Cloud SQL instances at all -- the options are either to use the non-standard cloud SQL proxy sidecar app, or allow connections from all endpoints (public or private). This seems like a major omission, and AWS has had this for ages.

there is also a thirth option. A small pod listening for node changes on k8api, that whitelists ips on cloudsql. I have been using this since two years ago.

Re: Cloud SQL for PostgreSQL now generally available

#77

Post by Lunatic666 » Thu, Apr 19, 2018, 6:25 AM UTC

Last time I was at Google for a workshop (If you have the chance to visit Google, do it. The food alone is worth it), they didn’t seem to push CloudSQL a lot, because they wanted to guide people more in the spanner direction. Without a solid RDS counterpart however, I don’t think bigger companies will consider moving from AWS. Happy to see they changed their mind and continue to expand their SQL services. The competition by Google put a lot of pressure on AWS who seemed to be gotten a bit lazy. Google was ahead of the game with their global load balancers and network speed and quality. Now AWS countered with their 5th series C5/M5, which solve the bandwidth problem of the smaller C and M instances

Re: Cloud SQL for PostgreSQL now generally available

#78

Post by andydd » Thu, Apr 19, 2018, 6:25 AM UTC

flamingcow wrote: post #53

daj40 wrote: post #14

Earlier quoted context omitted.

The updates take the entire instance down for 2-5 minutes each month. While you can't avoid them, they can be scheduled for particularly low traffic times. If you're trying to avoid downtime, its a giant PIA. Even with HA enabled, you still lose master, slave and read replicas. Not entirely sure what they define HA as, but a mandatory monthly downtime doesn't usually fit into mine. [Update] That said, from what I und…

[I'm the Cloud SQL TL] I can't comment on timelines, but we're aware that customers are interested in more features around maintenance window scheduling, deferral, and notification, as well as shorter downtime for updates and smarter scheduling within a group of replicas.

Can you confirm that it's impossible to avoid downtime, even with HA, because of forced updates?

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.

Re: Cloud SQL for PostgreSQL now generally available

#79

Post by wikibob » Thu, Apr 19, 2018, 6:42 AM UTC

TurningCanadian wrote: post #58

aserafini wrote: post #29

Earlier quoted context omitted.

This is what I expect from Google. They are not customer-centric and no-one is really prioritising or cares about customer feedback.

You clearly have never talked to GCP support. They're in a different league from AWS support.

As someone considering GCP, could you relate a story or two about GCP support’s technical competence specifically?

Re: Cloud SQL for PostgreSQL now generally available

#80

Post by sudhirj » Thu, Apr 19, 2018, 7:03 AM UTC

optimusclimb wrote: post #59

Started down the path of using this when it was in beta, but had to abort when we saw there was no option to connect to it from Python App Engine Standard. Now that it's GA...it looks like that hasn't changed. Is the classic, Python, App Engine standard becoming a second class citizen? Or was there some reason why this wasn't considered GA worthy for Postgres? Trying to understand if going forward Google is trying to…

I wouldn't say second class citizen (just yet) but the docs and Googlers have been gently nudging people to the flex environment. It can do everything the standard one does and more, so there's really very little reason to stick around on standard.