41–50 of 80 posts
That’s incredible. I wasn’t expecting them to allow you to run AlloyDB on premise but this is a potential game changer for on-prem Postgres instances, especially if you are doing analytical queries on the same data set.
Eh, there are other options for this that are more mature and more likely to be supported in the long run. The Citus columnar store extension has been around for almost a decade.
This looks really sharp. I wonder if Alloy gives some of the data compression benefits of columnar databases with that hybrid approach?
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 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.
Google Cloud gets a lot of heat because of Google's legacy of killing things off (the exact opposite of what enterprise decision makers want when selecting a cloud platform). But I have to applaud Google for the excellent first party emulators and local tooling that they provide (Alloy Omni doesn't seem like an emulator on first readthrough, but enabling fast local iteration has the same effect). The Firebase emulato…
At least there is a Cosmos emulator... There has been a ticket open requesting an Azure Service Bus emulator for FIVE YEARS lolsob https://github.com/Azure/azure-service-bus/issues/223 Which is too bad, because ASB is awesome, IMO the best Azure service.
Why 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, from a manageability, on top of the index advisor, there's also vacuum management, so it will figure out when the best time to do the garbage cleanup while minimizing impact on performance.
Gitpod:
2023-03-29 18:13:54.044 UTC: [alloydb_util.sh:90] FATAL: Docker service must be active to run AlloyDB Omni
2023-03-29 18:37:55.236 UTC: [alloydb_util.sh:76] FATAL: AlloyDB Omni requires cgroups V2 to run.
2023-03-29 18:53:52.766 UTC: [alloydb_util.sh:44] AlloyDB requires at least 16GB of RAM to run. Only 7 GB available. Please increase available RAM and retry
Earlier quoted context omitted.
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?
Tried running it on the cloud dev environments I usually use (as I am on Windows myself). Gitpod: 2023-03-29 18:13:54.044 UTC: [alloydb_util.sh:90] FATAL: Docker service must be active to run AlloyDB Omni GitHub Codespaces (after increasing memory): 2023-03-29 18:37:55.236 UTC: [alloydb_util.sh:76] FATAL: AlloyDB Omni requires cgroups V2 to run. GitHub Actions: 2023-03-29 18:53:52.766 UTC: [alloydb_util.sh:44] AlloyD…
Earlier quoted context omitted.
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?