Re:Cloud SQL for PostgreSQL now generally available
by misterbowfinger on Wednesday April 18, 2018 @08:31PM
(#16872464)
what's the benefit of using them vs. AWS or GCP directly?
[ Parent
| on HN ]
Re:Cloud SQL for PostgreSQL now generally available
by manigandham on Wednesday April 18, 2018 @09:42PM
(#16872723)
Latest software (using v10.3), better performance (nvme SSDs), better backups (point in time, instant cloning), better features (more extensions, cross-region replication even across different clouds), better flexibility (migrate master across different clouds), better monitoring (logs and datadog metrics export), and more focused support with a smaller team.
Re:Cloud SQL for PostgreSQL now generally available
by bpicolo on Wednesday April 18, 2018 @09:59PM
(#16872785)
AWS and GCP both have nvme SSDs for instance types intended for big-ol DBs
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-inst...
Re:Cloud SQL for PostgreSQL now generally available
by manigandham on Wednesday April 18, 2018 @10:29PM
(#16872900)
Yes, I know. This thread is about managed database services, specifically about Aiven vs cloud-direct. Aiven still runs VMs on AWS or GCP but offers nvme disks while neither RDS nor CloudSQL have that available.
Re:Cloud SQL for PostgreSQL now generally available
by bpicolo on Sunday April 22, 2018 @08:58AM
(#16895969)
Ah I see, i3 isn’t in the RDS pool yet. I imagine it will be eventually?
Re:Cloud SQL for PostgreSQL now generally available
by sandGorgon on Wednesday April 18, 2018 @11:50PM
(#16873201)
It's way more expensive. Have you found ROI there ?
Re:Cloud SQL for PostgreSQL now generally available
by manigandham on Thursday April 19, 2018 @12:03AM
(#16873248)
For our needs, yes. They run on cloud VMs so there will be a markup but their startup-4 and higher plans on GCP use local NVME SSDs so we get much better performance for the price.
We also make use of cross-regional replicas and are looking at doing it across clouds so if you want that then there isn't any other option other than doing it yourself. It's more of the complexity of this deployment rather than raw db size for us so if you have several TBs then maybe it's not the best fit.