Google Cloud SQL now supports PostgreSQL 13
cloud.google.com
cloud.google.com
We were using their managed MySQL instance. Without any communication, they pushed a silent update which broke our year-long security system that updated MySQL _priv tables in line with specific permissions and roles. There is no workaround.
When I reported the bug, it was labeled "Working as intended," again with no communication from Google as to why this breaking change was made, or even confirmation that it was something that Google changed at all. We spent days trying to figure out why we could reproduce it in some databases but not others, including diving into the MySQL source code.
I don't have experience with their Postgres product, but pushing breaking changes to a database with no notice or communication (either before or after doing it) simply isn't acceptable.
> Direct modification of grant tables using statements such as INSERT, UPDATE, or DELETE is discouraged and done at your own risk. The server is free to ignore rows that become malformed as a result of such modifications.
We have battle-tested tooling that makes this work brilliantly in all other environments. Updating the _priv tables directly is the only way to modify privileges within a transaction in MySQL.
Out of genuine curiosity, why do you want to do that? Is the transactional consistency of the applied permissions critical?
There seems to be a common pattern across Google's services of trying to force best practices on users at the expense of breakages. I suspect though that users are more likely to think "screw you Google, stop breaking my stuff" than "thank you Google for forcing me to follow best practices".
You’re using unsupported functionality that may break at any time, and you are using a managed database service that automatically updates. I don’t think you would have had a better time with any of the other cloud providers.
Google broke it without warning. That's a breaking change to your database, in production, 5 years after v5.7's release when you're fully locked in without so much as even a version bump.
Microsoft didn't do this. AWS didn't do this. Google did this.
Let this be a lesson to everyone that Google can and will break your critical production systems even years after they're operating perfectly, and they'll provide no warning, no explanation, and no fix.
Having said that, it is worth emphasizing that you relied on unsupported / discouraged behavior that "is at your own risk". This isn't just any random feature Google disabled, it's security-related behavior that is discouraged to rely upon by MySQL themselves. This is a big caveat, and is something that I would never recommend anyone to do, especially not when you're planning on outsourcing the management + maintenance of your database.
What this means is, while thorough testing can give confidence it works at some point, there is no real guarantee it will continue working even without any changes on our end.
Absolutely this. GCP has no responsibility here.
I've been using Aurora because it's managed, I don't have to worry about backups, it's faster and cheaper and easier to scale, etc.
But Postgres 12 has some really important features and performance improvements, and we really need them for my app. I've got to wonder why I'm paying for a managed service when they can't even manage to do a major version upgrade in a year.
Amazon supports PG 12 and 13 is in beta. Aurora is Amazon's fork of Postgres which has different storage and replication so will always be behind.
Honestly I don't know if they're even working on MySQL 8 for Aurora MySQL
A dump and restore is simply not viable for a database of any size. 100GB datababase which is not at all in the "large" territory would be down for at least an hour if not longer.
Pg_upgrade is generally the right shape of thing for this problem. One could debate whether replication is a better approach for even reducing that down time. (Pg_upgrade is on the order of minutes, it is not a size of data operation but rather a size of catalog operation). But that dump/restore is acceptable and the best option isn't really the case these days.
In that case as long as the source has some form of decoding (test decoding plugin or pgoutput) it should work.
That a dump is always the best process anything isn't really true these days (I know someone will show up with a case of why dump is 100% for what they need in moving data around). But, the combination of logical decoding, and pg_upgrade cover most cases.
Admit I was jumping a bit with upgrades, but that is where dump/restore does most often come up, not with migrations.
Disclaimer: I work for Google on a different project.
If you're on GCP already, of course you'd opt to use their managed Postgres service, otherwhise you'd have to worry about egress traffic, transport encryption, IAM, etc by yourself (or pay someone else do it for you, of course, making it more difficult to calculate your infra costs, having a 2nd support contract, etc) without much benefit.
How do you know that Google isn't supporting Postgres in any way, e.g. by supplying upstream patches, etc? The same goes for AWS, Azure, Heroku.
There's a list of contributors and what organization they're from here <https://www.postgresql.org/community/contributors/>. You won't see "Azure" listed but that's because it's considered part of Microsoft. Of the ones you listed, Azure is the only one that is considered a major contributor though you'll see there are companies that specialize in managed Postgres specifically.
edit: I thought they support "replica" but not "logical" thus the question
Logical replication allows you to create replication slots and send it to other places. It does allow for more interesting things as well. One really common use case (not even migrating off) is change data capture out of Postgres into Kafka leveraging Debezium. In older versions of Postgres you could use wal2json for this, now more more recent versions with logical replication supported the pgoutput plugin is great here.
Upgrades are a thing, but in place upgrades can be fully captured without logical replication. The short is though they are limiting a lot of what Postgres can do by not supporting it.
Disclaimer: I'm the lead of Debezium
New to cloud.
There is nothing stopping you from renting a VM and running whatever you want.
What I'd like is to pay for what I use when calls are being made. Providing an SQL interface as a service, rather than actually running a whole personally copy of a database.
But if you want "Read a tiny table once an hour, carry out a simple action in the circumstances are right" then paying for a database to be taking up a core 24/7 is not going to work for you.
So I wish it scaled down as well as up.
Ok, here are some: if you resize your instance you will get a downtime.
There is no support for CDC.
You pay for multi master but failover is painfully slow
If you launch more than one using terraform all except one will fail and will stuck in an unrecoverable state
They broke something last week so our proxies lost connectivity
CloudSql is a misleading name and a bad product.
Your first comment was not in line with HN guidelines. Your second comment is much better because it gives reasons.
I would have downvoted your first (and I do not work for GCP, mind you); I am now inclined not to just because you posted the reasons in your second comment.
Just before that Google failed to properly implement the payment settings to continue my Youtube Premium subscription at my previous price in the bundled GPM monthly packaging that I received. Thus, I lost access to both GPM and YT premium in single day.
I will never purchase another Google product.