Hacker News Reader

Comment by lysecret | Hacker News Reader

Hugely disappointed by Alloydb. Price and performance for a write heavy workload where off the charts horrible. It didn’t even support disabling an instance and it did only storage autoscaling much worse overall experience than using Aurora we moved back to cloudsql.

Does someone have good experience with Alloydb?

View on HN

Just 2c about disabling an instance - you can delete all the instances of AlloyDB on a cluster for a time being and recreate after. The data will be safe - they are on a cluster level

I have many thoughts here...but let's start with: Do you have your process of how you tested performance? My guess is the eng team would love to look at what you tested.

thank you for the measured response rather than immediately becoming defensive :)

WHAT DO YOU MEAN?! RAAAAAGE!! ;)

I mean, if someone legitimately finds workloads that aren't performing well, our engineering team SHOULD want to know about it, right?

Do they?

Okay, I can't speak for ALL engineering teams, but at the very least I know THIS engineering team absolutely does.

As a general feedback I have written it down here before: https://news.ycombinator.com/item?id=34304376

Sorry for being a bit negative but I was very excited for AlloyDB as a potential serverless offering for Postgres. Especially after having good experience with Aurora. And we ended up wasting a decent amount of resources migrating to and then away from it, thus my frustration.

In our use-case we use Postgres essentially as a cache. We have many cloud runs (approx 100) writing a lot of data in parallel which we then on a schedule query in certain ways and put it to GCP. Its quite a bit of data, about 1 TB a day.

It was a very CPU bound effort and to get acceptable performance we had to rely on the 8 core configuration, and we couldn't reduce the memory (from 64). We were getting similar performance with a 4 core 8gb Cloud Sql instance.

Probably not the most representitive workload but this had exactly the opposite effect to what we wanted (e.g. much more wasted resources and less serverless).

Also the fact you couldn't disable it was an absolute joke (we have prod dev and staging env and if we have to have a big always running DB for each of them, you can see how that is unacceptable).

We are happy with CloudSql though.

No worries on the negativity! I totally understand. No one likes to have time wasted. :( I'm getting the more detailed info on the cache use-case to the eng team just so they're aware. Also, the can't disable it...so funny story. You can delete the cluster...save the $$$ on the AlloyDB side, and recreate it later and the data's still safely there. So the disable instance is 100% valid feedback (and has been raised before, I'll add your voice to it as well). And there's a workaround....sorta.

Just curious, have you tried Alloy with the PostGIS extension?

I've been trying to get my work let us use BigQuery for our geospatial vector data queries, because we've managed to break all the equivalent AWS products, Snowflake, and Databricks on our dataset. Regular Postgres + PostGIS takes about 30 minutes to run our query and BigQuery does the same in 4 seconds. Unfortunately, BigQuery is a bit of a pipe dream right now for us, so it would be interesting to understand if PostGIS benefits from some of the changes in Alloy.

The improvements we've made on the read side of things likely won't affect the geo data directly, BUT, depending on what other aggregate data you're combining with the geo data you might see some improvement from the columnar engine. Hard to know without digging in deeper on the queries themselves and schemas you're working with. I don't want to steer you down a path of moving a ton of data and infra just to look. Best guess is that it'll be a bit better, but likely closer to your PG experience vs. the BQ experience.

Really appreciate the reply! Everything you said makes sense. It does feel like it would be really hard to beat BigQuery at this kind of task. The main query we run is just comparing two tables geometry where one is a polygon/multipolygon column and the other is a column of points. We ask, are any of these points in any of these polygons? So it's N x M comparisons, pretty much worst case scenario and there's no aggregation. I've had a hell of time trying to optimize PG for just running this one query. On the bright side, I've gotten to learn about and try a bunch of different databases now though :)

My PM also reminded me, depending on the data set size too, if it's bigger than the buffer cache, we might see some improvements over PG as well from that (we've made memory improvements around that which might help potentially).

I haven't tried AlloyDB yet but I've found most of GCP is this way. I've had to perform several Cloud SQL db migrations this year because storage will auto increase (due to ephemerally high tmp_data) and cannot decrease.

Lots of other rough edges with their other services. I have to believe that Google doesn't dog-food their own services.

All clouds do that for databases

Reply on news.ycombinator.com