Google Cloud Launches AlloyDB, a New Fully-Managed PostgreSQL Database Service (techcrunch.com) 19
An anonymous reader quotes a report from TechCrunch: Google today announced the launch of AlloyDB, a new fully-managed PostgreSQL-compatible database service that the company claims to be twice as fast for transactional workloads as AWS's comparable Aurora PostgreSQL (and four times faster than standard PostgreSQL for the same workloads and up to 100 times faster for analytical queries). [...] AlloyDB is the standard PostgreSQL database at its core, though the team did modify the kernel to allow it to use Google's infrastructure to its fullest, all while allowing the team to stay up to date with new versions as they launch.
Andi Gutmans, who joined Google as its GM and VP of Engineering for its database products in 2020 after a long stint at AWS, told me that one of the reasons the company is launching this new product is that while Google has done well in helping enterprise customers move their MySQL and PostgreSQL servers to the cloud with the help of services like CloudSQL, the company didn't necessarily have the right offerings for those customers who wanted to move their legacy databases (Gutmans didn't explicitly say so, but I think you can safely insert 'Oracle' here) to an open-source service.
"There are different reasons for that," he told me. "First, they are actually using more than one cloud provider, so they want to have the flexibility to run everywhere. There are a lot of unfriendly licensing gimmicks, traditionally. Customers really, really hate that and, I would say, whereas probably two to three years ago, customers were just complaining about it, what I notice now is customers are really willing to invest resources to just get off these legacy databases. They are sick of being strapped and locked in." Add to that Postgres' rise to becoming somewhat of a de facto standard for relational open-source databases (and MySQL's decline) and it becomes clear why Google decided that it wanted to be able to offer a dedicated high-performance PostgreSQL service. The report also says Google spent a lot of effort on making Postgres perform better for customers that want to use their relational database for analytics use cases.
"The changes the team made to the Postgres kernel, for example, now allow it to scale the system linearly to over 64 virtual cores while on the analytical side, the team built a custom machine learning-based caching service to learn a customer's access patterns and then convert Postgres' row format into an in-memory columnar format that can be analyzed significantly faster."
Andi Gutmans, who joined Google as its GM and VP of Engineering for its database products in 2020 after a long stint at AWS, told me that one of the reasons the company is launching this new product is that while Google has done well in helping enterprise customers move their MySQL and PostgreSQL servers to the cloud with the help of services like CloudSQL, the company didn't necessarily have the right offerings for those customers who wanted to move their legacy databases (Gutmans didn't explicitly say so, but I think you can safely insert 'Oracle' here) to an open-source service.
"There are different reasons for that," he told me. "First, they are actually using more than one cloud provider, so they want to have the flexibility to run everywhere. There are a lot of unfriendly licensing gimmicks, traditionally. Customers really, really hate that and, I would say, whereas probably two to three years ago, customers were just complaining about it, what I notice now is customers are really willing to invest resources to just get off these legacy databases. They are sick of being strapped and locked in." Add to that Postgres' rise to becoming somewhat of a de facto standard for relational open-source databases (and MySQL's decline) and it becomes clear why Google decided that it wanted to be able to offer a dedicated high-performance PostgreSQL service. The report also says Google spent a lot of effort on making Postgres perform better for customers that want to use their relational database for analytics use cases.
"The changes the team made to the Postgres kernel, for example, now allow it to scale the system linearly to over 64 virtual cores while on the analytical side, the team built a custom machine learning-based caching service to learn a customer's access patterns and then convert Postgres' row format into an in-memory columnar format that can be analyzed significantly faster."
This really the right way to go? (Score:2)
Is the wire protocol + SQL dialect really the right abstraction layer for cross PAAS database compatibility?
Re: (Score:2)
I don't want to be overly critical of Google here either; I know both AWS and Azure already offer pgsql personalities on their native DB products. Certainly using pgsql as protocol and dialect choice also makes it easy to perhaps run your cloud-native application offline if you want to.
I get the market reasons. I just wonder if its the right technical approach.
One way ticket to the Google Graveyard? (Score:2, Interesting)
Three years? Maybe four?
How much is google giving back ... (Score:3)
to Postgresql ? Both financially and code wise -- this might legally not count as distribution as it all runs on Google servers.
Re:How much is google giving back ... (Score:4, Informative)
Even if Google did distribute Pg, the Pg license is like the MIT or BSD license, not the GPL, so they wouldn't be legally obliged to open-source any changes to Pg.
Comment removed (Score:5, Insightful)
Re: (Score:2)
They are not funding Mozilla to be nice to Mozilla.
As I understand it's a business transaction where they pay a certain amount to have Firefox's default browser search to be set as Google.
Or maybe even an anti trust thing so that they can say Chrome has competitors?
Good Balance (Score:2)
I've done a couple of those migrations, they can be interesting.
Slashvertisement? (Score:2)
AWS has had a managed and hosted Postgres service for what.. a decade?
So does Azure and IBM Cloud and many others.
Why is this news?
This is just a giant ad for Google Cloud.
Too bad google cloud is shit (Score:3, Interesting)
Authenticating programmatically is a PITA. Do you need a service account? What permissions? What scopes? And their documentation is written for people that know how their stuff works (ie: internal users). It's at least 10 times harder to get stuff to work on google cloud than AWS.
For more obscure services (I'm looking at you, DFA) all their samples don't work.
It's what AWS could have been if AWS had fucked up.
Re:Too bad google cloud is shit (Score:5, Interesting)
AWS leaves a lot to be desired and intentionally doesn't have complete APIs in quite a few key areas. If you've ever scratched your head on why AWS APIs don't do something blatantly obvious (e.g. the ability to delete something via the API that can clearly be done via the Console), that is an intentional "by design" decision! I refuse to touch AWS as a result of that. IMO, DigitalOcean offers the vastly superior platform to Google Cloud, AWS, and Azure. I don't know who the big companies think they are catering to but it sure isn't me!
APIs: The Google Cloud API is horrible - a gazillion different account types and SDKs that are so bloated that even Google now has special instructions on how to reduce the SDK size down to a few MB. AWS APIs are a little easier to interact with but still have bloated multi-MB SDKs. DigitalOcean APIs are straightforward and can even use common tools like cURL to interface with the APIs (i.e. no SDK required as mother nature intended).
Console: Google Cloud and AWS have consoles that look and feel horrendous. Navigating those consoles is a nightmare. DigitalOcean is both pretty and largely navigable.
Cost: Google Cloud is more expensive than AWS and AWS is more expensive than DigitalOcean. At the end of the day, the bean counters want whatever is going to impact the bottom line the least.
Support: Google support for their own products is non-existent. Amazon support is barely competent - they think their broken systems are fine as-is. DigitalOcean actually has comprehensive technical support and fixes things that are broken - I've identified at least a dozen issues with their API over the years that they have promptly fixed.
Re: (Score:2)
I use DO as well, and its definately a very friendly design.
But its apples and oranges. AWS is a monolithically huge suite of services, whereas DO is a small focused suite. VM hosting and Kubernetes hosting aaaand thats about it. They really do have different use cases, some things just wouldnt work well with DOs offering, and other use cases DO is absolutely the best choice. IMHO the AWS vs Azure comparison is more useful (Unless you have a lot of need for windowsy things, use AWS. If you need lots of win
Isn't enough that all my data are belong to them? (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Before they had it, Google didn't realize just how messy your data was. They're just asking you to clean it up a little.
I wish they'd get rid of the marketing names! (Score:5, Insightful)
Shit, just call it managed Postgres! I hate these damn marketing names that make it sound like some sort of new, innovative database! It's just Postgres without all the administrivia! Call it Postgres PaaS so we don't have confused customers when we try to explain it to them!
I realize AWS started this trend but it's time to kill it, or nuke it from orbit!
Re: (Score:2)
I don't know anything about the Google offering, but Aurora is not Postgres.
It probably shares a lot of code, but you need to think of it is a database with a Postgres compatibility layer.
For instance, a complex query that makes the query executioner write out a temporary join table will work fine if you install Postgres on your local box, but can cause an Aurora instance to thrash and eventually crash because Amazon forgot to come up with a solution for temporary table space.