Live data from Hacker News

Cloud SQL for PostgreSQL now generally available

cloudplatform.googleblog.com

41–50 of 108 posts

Re: Cloud SQL for PostgreSQL now generally available

#41
post #13

How do you deal with custom extensions (for example plv8)? I started off with heroku and they don't support the same subset: https://cloud.google.com/sql/docs/postgres/extensions https://devcenter.heroku.com/articles/heroku-postgres-extens...

They don't have a great story around extensions - the ones they do have are unsupported/buggy. For example, PostGIS is missing "ST_FromGeoJSON" because it was compiled with the wrong flag - and has been this way for over a year despite hundreds of user complaints.

As someone who was migrating from on-premises to gcp, and who needs extensive postgis support, this information is a deal breaker for me. Is there any place I can find more information about postgis and other extensions status? Are you aware of any other bug related to postgis?

Thanks a lot for the information

Re: Cloud SQL for PostgreSQL now generally available

#42
post #13

How do you deal with custom extensions (for example plv8)? I started off with heroku and they don't support the same subset: https://cloud.google.com/sql/docs/postgres/extensions https://devcenter.heroku.com/articles/heroku-postgres-extens...

They don't have a great story around extensions - the ones they do have are unsupported/buggy. For example, PostGIS is missing "ST_FromGeoJSON" because it was compiled with the wrong flag - and has been this way for over a year despite hundreds of user complaints.

Disclaimer: I work on GCP

Can you point me to the complaints? I will take a look.

Re: Cloud SQL for PostgreSQL now generally available

#43

Earlier quoted context omitted.

They don't have a great story around extensions - the ones they do have are unsupported/buggy. For example, PostGIS is missing "ST_FromGeoJSON" because it was compiled with the wrong flag - and has been this way for over a year despite hundreds of user complaints.

This is what I expect from Google. They are not customer-centric and no-one is really prioritising or cares about customer feedback.

Still working for AMZN?

Re: Cloud SQL for PostgreSQL now generally available

#44

Earlier quoted context omitted.

This is what I expect from Google. They are not customer-centric and no-one is really prioritising or cares about customer feedback.

Still working for AMZN?

It appears not since 2011, according to the information sources you would have looked through.

Re: Cloud SQL for PostgreSQL now generally available

#45
post #17
post #10

I'm looking around for more details on these "regional" disks that replicate between two zones at the block level. Is that just a fancy term for os level mirrored disks using the cloud persistent disks?

There's a previous blog post[1] about HA replication. It uses block-level replication managed by PD infrastructure. [1] https://cloudplatform.googleblog.com/2017/11/Cloud-SQL-for-P...

Block device based replication for Postgres seems a bit unconventional given that Postgres has native synchronous replication support with WAL streaming.

Intuition tells me that you might get better performance if you let the DB itself do the replication but I can't really justify that without real review of what happens.

The postgres docs (https://www.postgresql.org/docs/10/static/different-replicat...) say that the WAL solution has no "Master server overhead" in contrast to the File System Replication solution, but it's not explained and I'm not sure what is meant by that.

I guess with a block device based solution, recovery takes longer, because failover entails you have to actually mount the block device (as no 2 machines can mount it rw at the same time), and then start the DB (or in a more basic implementation, just boot the entire second machine as part of failover), while with WAL streaming both postgres instances would already be running? Wo failover would be faster with WAL streaming?

I would be great if somebody from GCP could elaborate what the tradeoffs here are, how long failover takes, and whether we can expect similar performance and behaviour as with WAL shipping.

Re: Cloud SQL for PostgreSQL now generally available

#46
post #25

Does anyone have insight or experience using this in production? We're currently running PostgreSQL 10 w/ pg_partman on our own hardware but looking at a several options for cloud migration. Unfortunately, Citus Cloud on GCP doesn't appear to be an option (yet?) - Google Cloud SQL (PostgreSQL) - Citus Cloud (AWS Only) - Citus (managed ourselves) on GCP

We did, but now use https://aiven.io Highly recommended if you want a fast and featured managed db service.

what's the benefit of using them vs. AWS or GCP directly?

Re: Cloud SQL for PostgreSQL now generally available

#47
post #25

Does anyone have insight or experience using this in production? We're currently running PostgreSQL 10 w/ pg_partman on our own hardware but looking at a several options for cloud migration. Unfortunately, Citus Cloud on GCP doesn't appear to be an option (yet?) - Google Cloud SQL (PostgreSQL) - Citus Cloud (AWS Only) - Citus (managed ourselves) on GCP

From the big players there's also Azure (https://azure.microsoft.com/en-us/services/postgresql/) and Amazon (https://aws.amazon.com/rds/postgresql/)

Re: Cloud SQL for PostgreSQL now generally available

#48
post #45
post #17

Earlier quoted context omitted.

There's a previous blog post[1] about HA replication. It uses block-level replication managed by PD infrastructure. [1] https://cloudplatform.googleblog.com/2017/11/Cloud-SQL-for-P...

Block device based replication for Postgres seems a bit unconventional given that Postgres has native synchronous replication support with WAL streaming. Intuition tells me that you might get better performance if you let the DB itself do the replication but I can't really justify that without real review of what happens. The postgres docs ( https://www.postgresql.org/docs/10/static/different-replicat... ) say that t…

Just speculating but it’s possible the block level is faster because it’s replicated over a dedicated and optimized SAN rather than (potentially) contending with normal network traffic. I assume the database state would only be crash consistent though.

Re: Cloud SQL for PostgreSQL now generally available

#50

Is point in time recovery available now in GA? I had checked it a couple of weeks ago for the beta service and it was not available. I think for a managed DB hosting point in time recovery is a critical feature.

[I'm the Cloud SQL TL] No, it isn't. We agree with you that it's an important feature for managed databases, and we're working to get it right. We decoupled it from this launch to get PostgreSQL to GA faster.
Post reply on HN