It's repeated enough that it's a conscious decision. Google offers good application platform, but locks in the data layer.

See AppEngine. Had (and still has) much bigger potential than heroku since the beginning. But where do you store data? Random stores with random limits.

CloudSQL is great? Backup/restore in CloudSQL is half baked. Multi master for MySQL is half baked. All these are very well solved with RDS, but Google wants to sell you 3 or 4 different data stores with different arbitrary limits.

AWS free tier provides a tiny RDS insurance for you to store useful data. Google cloud free tier? No standard SQL databases. Again, arbitrary locked in custom nosql with random functionality and usage limits.

It's spread out enough that it looks like a planned strategy to give an open computation platform but lock in the data, even at the risk of driving away potential new/small customers.

+100 - i was waiting for them to launch Postgres prod. It just doesnt go live. Even worse, they have had trouble in exposing max_connections as configurable PostgreSQL flag (https://issuetracker.google.com/issues/37271935)

That is an understandably automatic control feature to keep the DB instance running well since PostgreSQL doesn't handle connection scaling well. The recommendation is to use pgbouncer, which you can also combine with the GCP cloudsql proxy into a separate container and use that way.

We deploy that onto GKE as a service and have our apps use that. Some setup required but cleaner overall.

I assume CloudSQL is google’s alternative to AWS RDS. Less of an excuse to not make the setting user configurable when the competition (AWS) does.

It's a double edged sword. When you don't limit connections and customers push their servers beyond their limits, some of them then ask why Google didn't do anything to prevent the situation from happening. Ideally, this would be solved by having better failure modes but that's not really the case today.

Most product decisions are not set in stone and can be changed if there's sufficient evidence to suggest that they do more harm than good. There's a lot of work that goes on behind the scenes to keep the service running smoothly and unfortunately/fortunately customers are not exposed to them. Some things that may appear to be simple on the surface are not when you take things like supportability into consideration.

Source: Used to work on Cloud SQL

There's no excuse, it's about a different philosophy.

AWS gives you lots of tuning controls and complexity while GCP tends to hide most of it with easier scaling and performance. It'll vary with individual products themselves but it looks like Cloud SQL is designed with that general outlook.

None of the clouds are perfect, the only viable strategy is to use the best parts of them all that fit your needs.

I'm afraid all of you are getting it wrong. The setting is hardcoded to 100.

Check this out - https://issuetracker.google.com/issues/37271935#comment39 and then the update https://issuetracker.google.com/issues/37271935#comment49

This is not a feature. It is a bug. It needs to be at par with RDS.

As actually stated in the comment you linked to, it is not hardcoded but scales with the instance size to protect against an out-of-memory condition. The lack of it being user configurable is a separate issue, and not a bug but rather a design detail of their managed service.

It's a product decision to not make this configurable to make the service supportable. It's not a technical issue.

I don't know if Google advocates horizontal movement to different orgs/teams specifically, or if its just anecdata I've picked up talking to Googlers and reading about their org structure, but I wonder if this and the promotional scheme of "launch and move on" has caused teams to splinter and lose serious velocity - becoming the direct cause to stuff like this.

Personally I think Google App Engine has always had massive potential but has been at about 80% of its potential since its inception.

EDIT: Also I don't want to take away from this press release, the CLI is awesome and its going to help a lot of people.

> I wish they would spend more time finishing the halfway done projects they've started (and fully documenting them), rather than continue to launch new ones.

Perhaps I am reading too much into your comment but you make it seem as though releasing other products slows down the development of those projects that you consider halfway done.

This is definitely not the case; it's not as though the engineers who were working on CloudSQL or AppEngine decided to start working on a CLI instead.

> I think recent articles I've read about launching being the track to promotion explain some of the state of things within GCP.

There are certainly issues with promotion but if anything I'd imagine getting a highly requested customer feature like Postgres out of beta would be awesome for promotion so I don't think that's the underlying issue here.

This -- _so_ much. That was my first thinking as well.

IAM in GCP is still half-baked. How about they finish that? I understand that GCP is a massive engineering effort with endless things going on in series, but core parts of their platform are still mediocre at best. I'd prefer not to see more hackweek projects on their blog.

What feature do you need from IAM?

gcp pm here - got time to chat?

Real IPv6 support is another one. I get that it's harder for them because they do such advanced networking at such a scale but... at this point their statements of support seem like empty talk. They are a late adopter.

We don't know if they have teams working on this or not...my guess is they do. What if it just takes a long time to ship those features to GA? Should they hold off on other features?

Yeah. Google Cloud Functions - Beta. Also had a multiple hour outage recently. Been waiting for Postgres to move out of beta for ages.

The good thing about Google Cloud is that once things are out of beta, it is usually easier, cheaper and often faster to use than AWS equivalents. The "AWS way" of charging of every little thing is migraine inducing. (Ex. IOPS for RDS is tied to instance size but can also be scaled independently.)

Hi all, the Google Cloud SDK team here. The Interactive CLI feature is currently in Alpha, but part of our overall Cloud SDK. The SDK is very much in GA, but we continue to look for your feedback on what we can do to make the SDK experience better and easier to use. If you’ve got feedback, we have a built-in mechanism in the SDK. Just enter ‘gcloud feedback’, and let us know.

I have 300$ of trial credit, but couldn't use it when I wanted to create Cloud Datalab notebooks for an ML MOOC under the pressure of deadlines. I was willing to spend more money on something that is working (Floydhub) than use these GCP credits and figure out how to use it.

That's the biggest problem with GCP. Not these small projects (since they have multiple teams working on things and everything progresses in parallel) but the very big lack of managed services and polished features.

The underlying tech and building primitives are the best, so if you just need fast VMs with solid cpu/io/networking then it all works well. Unfortunately that's not enough to compete with AWS and Azure which have so many turnkey services that let you focus on more productive things.

I've been waiting for Cloud Postgres as well and wish I could have used it on my most recent project. I was told last month by a "Cloud Specialist" that they were targeting early Q2 of this year to leave beta, but I'll believe it when I see it.

I also find it frustrating that they don't have more turnkey services. In particular, search. It's ironic that Google's doesn't offer a search service (except if you use App Engine).

>I wish they would spend more time finishing the halfway done projects they've started

Do you expect other teams to halt what they're doing and wait for other teams to finish before they continue their work?

No - I wish they'd release fully baked features before starting new ones - i.e. there'd be nothing to halt. I realize it's not that simple, but, generally speaking - I do not see near the level of readiness/polish/documentation out of existing features as exists on AWS.

It seems that it is the same problem that plagues Google as a whole.

Google is notorious for this behavior. Don't you remember the years-long "beta" status for GMail?