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 how does it compare to PGHero for index advising?
We encourage folks to draw their own conclusions, but we have done comparisons and ours is more efficient and produces faster results. I only say test yourself because I can't give specific details of how/why, so don't take my word for it. :)
We don't have specific details yet about licensing or pricing. Stay tuned as we get closer to GA. Having said that, we're pushing hard for a free usage tier and the product team isn't pushing back. :)
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 essent…
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.
> 3. Use of the Software. > 3.1. Use. You may authorize employees, agents, and subcontractors to use the Software in accordance with this Section 3, so long as you remain responsible for them. You may make a reasonable number of copies of the Software for back-up and archival purposes. > You acknowledge that the Software is a preview offering not intended for production environments, and you agree that you will only…
For those who want to skip the gsutil part, that bucket and its keys are public:
Maybe I'm old.. but everytime I read Alloy I think of the old modeling language out of MIT to prove a program's correctness. Gives me PTSD thinking of grad school.
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…
Definitely not an emulator. It's fully AlloyDB...in a container. We'll be working moving forward to smooth out the install process (tech preview, focus was on getting it in y'alls hands). In my mind, it's a proper Postgres drop-in replacement (Yes, of course I'm biased because I work at Google) but the tech is legit.
Fair but maybe drop the open source tag on the blog post, since it’s not?
I’ve gotta say without unambiguous and long term unencumbered licensing, preferably with open source attached, I can’t foresee recommending any place I’ve got influence at to even look at it yet. Hopefully you can push them in a direction that is plausibly usable by anyone other than hobbyists. Even as a local dev tool it leaves too many holes open in the licensing and distribution model. Letting a team build a proce…
100% hear you. I realize this may sound hollow coming from a Google employee, but stay tuned on specifics around licensing and costs. Being a tech preview, there's been virtually no discussion on specifics yet. We just wanted to get the tech in folks' hands. We're pushing hard for a free tier of usage (and the product team isn't pushing back currently).
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?
It's twice as fast as out of the box PG for most things, and up to 100x faster for reads, depending on what you're doing. So there's that. 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.
The 100x analytics seems due to columnar storage like with TimescaleDB, but how do you get improvements on the other things? Is it really faster on a database with good indexes?