Hacker News Reader

Comment by optimusclimb | Hacker News Reader

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 push everyone to the flexible environment or not - as I would have really expected connectivity between these two products.

View on HN

[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. :(

Thanks. Could you please explain in a little bit more detail how it works for Java GAE Standard and not Python?

Thanks for that, but...not using Java.

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.

From the docs:

https://cloud.google.com/sql/docs/postgres/connect-external-...

> You can grant any application access to a Cloud SQL instance by authorizing the IP addresses that the application uses to connect.

> You can not specify a private network (for example, 10.x.x.x) as an authorized network.

> PostgreSQL instances support only IPv4 addresses. They are automatically configured with a static IP address.

Ah, misremembered exactly what the issue was -- you're right, individual endpoints can be whitelisted. Internal networks cannot, which is what I (or anyone else using GKE) would need, since node IPs are ephemeral.

I believe the same issue would apply to VM instances that are not pets, (in auto-scaling groups for example), since I'm not aware of being able to auto-assign static IPs there either.

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.

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.

Cost maybe?

Well if they provide a free tier for flex, that is equal to standard, I wouldn't bother switching.

Why not use AWS though? It is so much better, reliable and overall super cheap.

Reply on news.ycombinator.com