This was a tough call for the team: ship now for the folks that are okay with that, or wait until it's fully baked. They chose the former, which certainly means it's not a great idea for serious production load, but that's also true of it simply being in Beta. You won't see it go GA before it's really ready for production work (including replication, backups and so on) but I think it was a reasonable choice to get people started.

Disclosure: I work on Google Cloud (but not Cloud SQL).

I realize you can't commit to any particular dates, but is your feeling that this is .... single digit months away, or multiple digit months away, from being out of 'beta'?

Good question! Because of those important bits of functionality that will keep rolling in during the Beta, I'd say single digit months to the most important ones.

As a point of clarification though Beta => GA is about production hardening. Products can't go to GA without demonstrating that they've met their SLOs continuously for several weeks. Products can take longer than that if they feel they should make more tweaks first (and pgsql certainly qualifies), but we want to both ship quickly and get out of the reputation for perpetual Beta.

thanks! :)

It's a great idea. Customers can start using it today to host the databases for their dev and QA environments, which will help suss out any issues with it before GA.

I'd generally want at least my QA environment to be a replica of my productions environment, and I guess many others would too.

I don't want to be overly negative though - releasing now at least let's us play with it and see how it stacks up.

Many teams/companies have multiple QA environments...

Is there any formal statement of whether and how much notice might be given if Google decides to discontinue this service?

The message at the top seems to me to make clear is could be discontinued at any time with zero notice.

As soon as it gets out of beta, it will get an SLA and deprecation policy of hopefully 2+ years notice before it gets discontinued.

That's certainly the letter of the law, but it's pretty clear Cloud SQL is here to stay.

Hello!

This might is bit off topic on this thread.

Seems like there is some confusion going on about the Free tier on a post[1]. Can you please comment there on whether the 'Always free' is free only during the first 12 months or forever?

Also, if I have been using Google Cloud since before today (when free trial was $300 over 60 days), am I still eligible for the 'Always free' tier?

From the page linked and the FAQ, it looks like it but many people on the thread I've linked are thinking otherwise.

Can you please clear that up for us? Thank you!

[1]: https://news.ycombinator.com/item?id=13832519

Sorry, we've made updates to clarify. Yes, you can use during and beyond the free trial. Even though your free trial has expired, you can still use the Always Free products.

Thank you!

Another quick question. Is there anyway to see during instance creation/usage if it is part of the free tier?

When I create a f1-micro instance, it shows the usual $5/month billing, but doesn't indicate any kind of 'free tier' usage. How can we know if any service we use will be a part of the free tier for sure? I guess I can wait a few days to see if any costs accrue, but I was wondering if there was a better way for everyone.

Is there a way to see if the Cloud SQL team is planning to add more extensions? I'm mostly interested in citext myself but seeing that many people mentioned extensions, it would be nice to have some visibility in that.

More extensions is something we definitely plan to do.

No timeline, partially because we don't know ourselves. Our main priority for next few weeks will be ensuring everything is nice and stable. Once we are confident in current feature set we will start adding more. You can watch https://cloud.google.com/sql/docs/postgres/release-notes for news.

Source: I work on Cloud Postgres.

Regarding being beta, the flexible environment instances for App Engine are/were beta (I swear it was just a couple days ago, it was labelled beta, but not seeing it now). All the same, a lot of people are building towards that (ie Docker).

App Engine Flex just came out of beta today :)

https://twitter.com/googlecloud/status/839901710948589568

But in that case it was not without replication (ie useless).

(Ozgun from Citus)

As someone who interacts with PostgreSQL on-prem and cloud deployments frequently, I'm curious on the Hacker News community's thoughts on one question.

AWS has a fairly mature RDS Postgres offering. What would motivate you to use Google Cloud Postgres instead?

I've heard of four reasons from users: not on AWS, don't want to be locked into one vendor, cost, and better support. Do any of these reasons resonate with you or are there others?

What motivates me personally is not that I think Google Postgres will be better than RDS (which is great for us so far), but because I want to move to GCP for other reasons (pricing, better UI & cli, GKE, BigQuery) and the managed Postgres RDS was the only thing that was important enough to keep us on AWS

Same for us. We're migrating to GKE but are accessing Postgres over a gateway and leaving our DB heavy services on AWS... This was very good news.

Same here.

Plus RDS was the only reasonable option at that price tier (with high availability and multi-AZ). I think competition was sorely needed.

RDS was pretty much becoming a monopoly on this front.

Is [Compose](www.compose.com) comparable?

They have a HA postgres offering (not sure about multi-az) and I thought I'd heard good things about them in the past?

I just started using Google Postgres and, as of today, there is no way to easily get your PG data into BigQuery via any Google cloud service. You have to create your own CSV from your PG data, then upload that into BigQuery. I imagine (hope) this will change with additions to the Export options of PG instances.

I'd consider Google Cloud because the documentation, tutorials and verbose config (on most services) on AWS are a fairly substantial barrier. Has you ever gone through trying to wire up a Lambda function to talk to a S3 bucket and API getway endpoint? It's not fun. Even getting ElasticBeanstalk running with Docker isn't really easy.

I think Google Cloud is the middle ground between Heroku and AWS. It has potential to really gain traction with developers who want to get stuff shipped and not wear DevOps hats full time. What I'd like to see is Google adopting more modern software on their platform (Python 3) and trying to move things out of beta more quickly. You can't sell beta to management easily.

I'd consider Google Cloud because the documentation, tutorials and verbose config (on most services) on AWS are a fairly substantial barrier. Has you ever gone through trying to wire up a Lambda function to talk to a S3 bucket and API getway endpoint? It's not fun.

Strongly agree. I think that using an orchestration tool like Ansible or Cloud Formation is basically essential for AWS, because so many of the services have these interdependencies.

> Even getting ElasticBeanstalk running with Docker isn't really easy.

Yeah, we tried it. Not a great experience, and using an AWS proprietary container hosting system when everyone else is standardising on Kubernetes is not remotely attractive. I'm really looking forward to trying App Engine Flexible and GKE. If we can get really good application container hosting from GCP, then that will be a strong pull to migrating whole stacks.

I'd say the Elastic Beanstalk with a single container is very easy... zip your project with a Dockerfile, and it will create the container...

However, man that Awsrunfile or whatever it is called, and the two versions that are incompatible with the different EB versions, and it's painful... the hosted container solution equally so.

GC's docs and tools just seem so much more straight forward (as do Azure's for that matter).

There are lots of reasons to prefer Google, but ultimately there is one, single reason I want to switch:

The ability to cap costs.

With AWS, by the time you get a billing alarm, you could be thousands of dollars in the hole and there's nothing you can do about it. Avoiding that risk will help me sleep a little better.

I thought GCloud only had spending limits for App Engine services (including, apparently, Cloud Datastore even when used separately from App Engine), but not other services.

Thanks for alerting me to that possibility. If that's the case (can anyone confirm for sure?) then switching is probably not worth the switching costs for me right now.

As a Google customer (of both Compute/Container Engine and Cloud SQL), I'd rather use a Mysql instance hosted next to my application on Google's network than a Postgres instance that's an internet-hop away in Amazon's cloud. If I was currently running my apps on AWS that's where my DB would live too (and I'd be using RDS Posgres there).

The other reasons listed are an order of magnitude less important for my cost/benefit calculus (though things like cost and support will definitely matter to orgs bigger than mine).

Yes, costs is a big factor for me.

I would love to see your own cloud offerings on Digital Ocean and on Google Cloud. Hopefully, with that said, we'll also see much more reasonable pricing as well!

I'm curious what you'd like to see in terms of pricing from Citus?

Yes, we do start at a higher end $990 a month, but we're very much focused on heavier workloads. Typically users come to us at 100 GB or more. If you're well below that we encourage you to stick with single node Postgres either RDS or Heroku Postgres. Once you get close to a $1k a month spend on those then we can start to make sense to consider.

A multi node , 100gb postgres cluster can be had for 260$ per month if you choose yearly prepaid on RDS.

The price to performance ratio is fairly unbeatable.

Price to performance is a bit debatable.

Yes, you can absolutely get that much storage for that price. Though what your application needs in terms of memory/cores varies quite a bit on the application. We've seen customers that were spending $800 a month on RDS, migrate and get 2-3x performance boost for the same dollar spend.

Don't disagree at all that if you're at a lower volume of data that RDS is a great option for what you get. Depending on your application needs though as you scale and need more data in cache or more cores doing work, though this all depends on your workload. You can have 3 TB of cold storage and that work fine for your application and cost you under $1k a month on Aurora, or you could have needs with 100 GB of data that you need all queries served from cache in milliseconds. It's very unlikely you'll get that for $260 a month on RDS even at as little of 100 GB of data. It just depends on your application workload, for as long as you can you should just keep scaling up because it's much easier.

We very much focus on when you start to encounter that ceiling where scaling up starts to become prohibitive and performance is key not just storage–which can be as early as 100 GB, and is increasingly common the further you get beyond that.

which im agreeing on - I was trying to hint to make a tier for the 200$ users out there ;)

I use PostgreSQL on RDS. I wouldn't touch GCE for a year still it's had its kinks ironed out.

> it's a realistic option for production workloads.

Surely this is only true for certain definitions of 'production workloads'?

Well it is only in a beta state