Live data from Hacker News

AlloyDB Omni – run AlloyDB anywhere

cloud.google.com

31–40 of 80 posts

Re: AlloyDB Omni – run AlloyDB anywhere

#31

Earlier quoted context omitted.

> it's a proper Postgres drop-in replacement The only downside I see is that going through the deployment process, it seems that the smallest instance I can provision is 2vCPU/16GB which if I'm looking at the pricing table correctly, equates to $230/mo. for a single instance. The web console only lets me create a cluster with minimum 2 instances so it seems like I'm looking at $460 minimum to deploy Alloy. That feels…

You're looking at Cloud AlloyDB sounds like? If you deploy AlloyDB to GCE (instead of locally, etc) you can provision a smaller instance than that. 2cpu(shared core)/4GB memory with a 20GB boot disk (AlloyDB takes up ~13) would run you $26/month before network/storage costs.

Just my $0.02 here: if Cloud AlloyDB can deploy a big cluster, it seems like such a small stretch to take the same pipeline and deploy a small instance instead.

Re: AlloyDB Omni – run AlloyDB anywhere

#32
post #5

I wonder how they make transactional workloads 2x faster vs normal Postgres The analytics workloads improvements seem pretty straightforward (or at least there is prior art like timescale)

My best guess is that transactional workloads are mostly improved by automatically adding the right indexes and parameter tuning. For example, OtterTune also advertises "2x on price/performance over unoptimized DBs".

Re: AlloyDB Omni – run AlloyDB anywhere

#33
post #30

Has Google contributed some of these changes back to Postgres? I went looking and even a search for "alloydb" in some postgres mailing lists return no results. It has some very exciting features, I was a bit surprised to see nobody talking about it.

It's worrying that a lot of companies aren't pushing these types of changes back. Particularly with Google, they'll have software patents that prevent others from implementing the same improvements but also, based on their track record, will abandon this project within a few years. When that happens, their improvements will simply be inaccessible.

I realize this may sound hollow coming from a Google employee...but I am fighting to be sure something like this stops happening (in particular the deprecating causing loss of functionality). Google is (a little) better than it has been in the past. E.g. the opening of the protocols on the Stadia controllers when Stadia was shut down so their controllers could work on other platforms.

I am pushing at the OSS angle, but new product, so uphill battle. :)

Re: AlloyDB Omni – run AlloyDB anywhere

#34

Earlier quoted context omitted.

You're looking at Cloud AlloyDB sounds like? If you deploy AlloyDB to GCE (instead of locally, etc) you can provision a smaller instance than that. 2cpu(shared core)/4GB memory with a 20GB boot disk (AlloyDB takes up ~13) would run you $26/month before network/storage costs.

Just my $0.02 here: if Cloud AlloyDB can deploy a big cluster, it seems like such a small stretch to take the same pipeline and deploy a small instance instead.

Yah, I know. The Cloud version has a lot of stuff happening behind the scenes that makes it a bit trickier to have a smaller machine configuration. It's being worked on, but I can't speak to timelines/configurations.

Re: AlloyDB Omni – run AlloyDB anywhere

#36

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?

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 :)

Re: AlloyDB Omni – run AlloyDB anywhere

#38

Earlier quoted context omitted.

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?

Re: AlloyDB Omni – run AlloyDB anywhere

#39
post #23

Earlier quoted context omitted.

If I understand correctly, AlloyDB is a Postgres compatible re-implementation, so there's no shared code. So this is a bit like Wine compared to Windows, only with the big corp re-implementing the OSS software instead of the other way round.

You can't really be 100% postgres compatible without borrowing a lot of implementation

Query and storage layer are nicely separated in the Postgres codebase, you can absolutely rip out the complete backend if you really want it.

There is a Postgres interface to Spanner which probably did that.

Re: AlloyDB Omni – run AlloyDB anywhere

#40

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?

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
Post reply on HN