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.