Disclosure: I work on Google Cloud (but not Cloud SQL).
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.
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.
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!
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.
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.
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.
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?
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).
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.
They have a HA postgres offering (not sure about multi-az) and I thought I'd heard good things about them in the past?
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 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.
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).
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 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!
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.
The price to performance ratio is fairly unbeatable.
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.
Surely this is only true for certain definitions of 'production workloads'?