Is there any HA built into this? Performance claims look great.
AlloyDB Omni – run AlloyDB anywhere
51–60 of 80 posts
Re: AlloyDB Omni – run AlloyDB anywhere
#52Why would anyone use this as opposed to using Postgres? The value prop of run-anywhere applies to Postgres as well. I see column store and index advisor as the two features but if I don't need these, is there any reason?
also how does it compare to PGHero for index advising?
Re: AlloyDB Omni – run AlloyDB anywhere
#53This looks great! For the 2x general improvement, how much of that is due to setting/modifying postgres settings and adding good indexes, versus improvements to the code itself?
Re: AlloyDB Omni – run AlloyDB anywhere
#54Why would anyone use this as opposed to using Postgres? The value prop of run-anywhere applies to Postgres as well. I see column store and index advisor as the two features but if I don't need these, is there any reason?
We use Postgres as a Datawarehouse, once AlloyDB Omni is stable there is virtually no reason for us not to use it.
Obviously, we use Postgres not for its performance but for its ergonomics, first class dbt support and unbeatable extension ecosystem. Now if you're telling, I get all that with no compromises whatsoever and with a 10-100x analytical query performance increase, I'd be crazy not to use it.
From my perspective, Postgres just keeps on giving.
Re: AlloyDB Omni – run AlloyDB anywhere
#55This looks great! For the 2x general improvement, how much of that is due to setting/modifying postgres settings and adding good indexes, versus improvements to the code itself?
Code improvements. Indices aren't taken into account at all since that's so workload dependent. Having said that, the index advisor can make finding the right indices to improve performance there more easily as well. Vacuum management handles figuring out the right time to do garbage collection for you, etc. None of that is part of that 2x improvement.
Re: AlloyDB Omni – run AlloyDB anywhere
#56Why would anyone use this as opposed to using Postgres? The value prop of run-anywhere applies to Postgres as well. I see column store and index advisor as the two features but if I don't need these, is there any reason?
We use Postgres as a Datawarehouse, once AlloyDB Omni is stable there is virtually no reason for us not to use it. Obviously, we use Postgres not for its performance but for its ergonomics, first class dbt support and unbeatable extension ecosystem. Now if you're telling, I get all that with no compromises whatsoever and with a 10-100x analytical query performance increase, I'd be crazy not to use it. From my perspec…
100% I'm a huge PG fan as well. This should absolutely be "PG + performance and QoL improvements". Where it's not, we want to hear about it.
Re: AlloyDB Omni – run AlloyDB anywhere
#57Is there any HA built into this? Performance claims look great.
Not for Omni no. End-users are responsible for any HA/DR/Replication needs. Cloud AlloyDB has all of it built in, but since it was so tightly tied to the Cloud infrastructure it was simplified for Omni.
Re: AlloyDB Omni – run AlloyDB anywhere
#58What does it mean in terms of license?
Re: AlloyDB Omni – run AlloyDB anywhere
#59This looks great! For the 2x general improvement, how much of that is due to setting/modifying postgres settings and adding good indexes, versus improvements to the code itself?
Code improvements. Indices aren't taken into account at all since that's so workload dependent. Having said that, the index advisor can make finding the right indices to improve performance there more easily as well. Vacuum management handles figuring out the right time to do garbage collection for you, etc. None of that is part of that 2x improvement.
That's impressive, surprised there's that much juice that could be squeezed without changing architecture. I ask because AWS Aurora is flattered in comparison to RDS due to e.g. some dumb oob pg settings that a lot of people don't change.
From seeing the cloud alloydb I had imagined most of the improvements were due to the wal-shipping and cloud native aspects.
Re: AlloyDB Omni – run AlloyDB anywhere
#60Hugely 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.
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.