[HN Gopher] AlloyDB AI: Generative AI applications with PostgreSQL
___________________________________________________________________
AlloyDB AI: Generative AI applications with PostgreSQL
Author : jerryjerryjerry
Score : 77 points
Date : 2023-08-29 19:16 UTC (3 hours ago)
(HTM) web link (cloud.google.com)
(TXT) w3m dump (cloud.google.com)
| xnx wrote:
| Very cool that there's a "preview" downloadable version:
| https://cloud.google.com/alloydb/omni
| jadbox wrote:
| Is/will AlloyDB be open source?
| cheeseface wrote:
| No, it's Google's proprietary product meant to lock you into
| their Cloud offering.
| slig wrote:
| "Free while in developer preview, check back in the future
| for pricing". Too weird for me.
| viscanti wrote:
| After that you'll be able to pay for it for a year or two
| until they realize that running a business is a whole thing
| and then they'll just deprecate it and kill it off.
| yumraj wrote:
| As another person noted, there's a downloadable version at:
|
| https://cloud.google.com/alloydb/omni
| hmottestad wrote:
| "Available at a fraction of the cost of legacy databases,
| with a free developer edition"
|
| So I guess there is some kind of licensing model even
| though you can download it and run it on your own servers.
| yumraj wrote:
| Yes, perhaps there is a free developer edition, but for
| commercial deployment you have to use their cloud. That'd
| be a bummer..
| formercoder wrote:
| Disclaimer: I work on Google Cloud
|
| Yes it's commercial but you can run it on any cloud or on
| prem.
| mpercy wrote:
| How are people actually using vector databases?
|
| The closest explanation to a use case architecture I've seen
| recently was https://mattboegner.com/knowledge-retrieval-
| architecture-for... - it basically describes doing knowledge
| retrieval (keyword parsing) from LLM queries, feeding that to a
| vector db to do similarity search to get a top K similar
| documents to the parsed keywords, then feeding that list that
| back into the LLM as potential useful documents it can reference
| in its response. It's neat but it seems a bit hacky. Is that
| really the killer app for these things?
| ultra_nick wrote:
| Yes, GPU poor people are just using top k semantic search to
| try to fix the issues will low ram low knowledge LLMs. It's OK
| for some applications, but other methods need to be
| investigated.
| CharlieDigital wrote:
| We used it in an e-commerce application.
|
| Apparently, one of the hardest things to do is to match a
| product name + description to a product taxonomy.
|
| There are multiple taxonomies. Here's Google's for example:
| https://www.google.com/basepages/producttype/taxonomy.en-US....
|
| Amazon has their own. Walmart has their own. Target has their
| own.
|
| Given a list of tens of thousands of products, how can you
| automatically match the product to a merchant's taxonomy?
|
| I started with a "clever" SQL query to do this, but it turns
| out that it's way easier to use vector DBs to do this.
| 1. Get the vector embedding for each taxonomy path and store
| this 2. Get the vector embedding for a given product
| using the name and a short description 3. Find the
| closest matching taxonomy path using vector similarity
|
| It's astonishingly good at doing this and solved a big problem
| for us which was building a unified taxonomy from the various
| merchant taxonomies.
|
| You can use the same technique to match products with high
| confidence across merchants by storing the second vector
| embedding. Now you have a way to determine that product A on
| Target.com is the same as product A' on Walmart.com is the same
| as product A'' on Amazon.com by comparing vector similarity.
| whimsicalism wrote:
| > AlloyDB AI allows users to easily transform their data into
| vector embeddings with a simple SQL function for in-database
| embeddings generation, and runs vector queries up to 10 times
| faster than standard PostgreSQL. Integrations with the open
| source AI ecosystem and Google Cloud's Vertex AI platform provide
| an end-to-end solution for building gen AI applications.
|
| - Embrace [X]
|
| - Extend [X]
|
| - Extinguish [?]
|
| Will they allow it to use custom embeddings?
| insanitybit wrote:
| lol couldn't you say that Postgres is EEE for SQL? It embraced
| SQL, has added new functions and incompatible constructs to
| SQL... is it going to extinguish SQL next?
| TexanFeller wrote:
| It does provide plenty of PG specific capabilities, but PG
| has always had much better conformance to SQL standards and
| support for all the standard features than other DBs like
| MySQL. It's one of the most compatible DBs from a few points
| of view.
| insanitybit wrote:
| Yes, that's the "embrace" part.
|
| I guess my point is that "Embrace, Extend, Extinguish" is a
| really outdated saying and I hate it. Embracing and
| Extending are really good things.
| derefr wrote:
| The "Extend" stage is the key: it's actually supposed to
| refer to attempts to introduce "better" / "more
| advanced", but _proprietary_ and _inherently
| implementation-locked_ technologies into an
| implementation (and thus into the platform the
| implementation implements); where these technologies don
| 't complement, but instead _supersede_ the use of the
| platform 's existing open-standards capabilities, for
| those using this implementation.
|
| In the "Extinguish" stage, the open-standards
| capabilities are then _deprecated_ in favor of these
| proprietary technologies -- in theory just for the
| implementation itself, but in practice ecosystem-wide,
| due to the implementation 's majority user share. As the
| locked-in nature of the component makes it impractical to
| offer any other implementations of it, all other
| implementations "fall behind" due to lacking this
| component, supporting fewer and fewer greenfield
| projects, until users give up on them, "Extinguishing"
| their market-share.
|
| The "Extinguish" stage only makes sense insofar as the
| technologies introduced in the "Extend" stage _have_
| inherent implementation lock-in. Otherwise, it 's just a
| regular open-standards dueling-RFC-banjos scenario, not
| EEE.
|
| With Internet Explorer, the "Extend" phase was when
| Microsoft attempted to get people to write ActiveX
| components (that could only ever possibly work on
| Windows, since the ActiveX "platform API" is just "the
| entire Windows API") instead of writing JS. If doing this
| had become popular, no website that did it would have
| worked on any other browser than IE (and so there would
| have had to be "the ActiveX-enhanced IE version" and "the
| regular HTML version" of the site. Which _was_ actually a
| thing for a short while... though only on Microsoft 's
| own web services, AFAIK.)
| thewataccount wrote:
| I think what you're trying to say is that just because
| someone - especially [large company] - tries to
| improve/integrate popular open projects doesn't mean it's
| always EEE.
|
| Which I doubt EEE is purposeful the majority of the time
| initially, even if has the potential to become that later. In
| the case of google I think this would be a case of "how do we
| add value to our product to sell" followed by "this feature
| costs us too much resources to maintain, let's cut it and
| focus on [new feature]"
|
| That being said Postgres is not a good example because AFAIK
| they're both not a commercial entity (or any registered
| entity at all?) and they're true FOSS. At the moment they
| have no commercialization strategy (sponsorships maybe?) and
| no ability to extinguish anything given their open license
| and lack of any proprietary services.
| slig wrote:
| It's not like Google is famous for dropping projects.
| thatcherthorn wrote:
| > AlloyDB AI allows users to easily transform their data into
| vector embeddings with a simple SQL function for in-database
| embeddings generation
|
| Slick!
| hn1986 wrote:
| Is AlloyDB basically like Aurora DB for AWS?
| bearjaws wrote:
| Yeah its closest analogy is Aurora, but no serverless option,
| payment is per vCPU, memory, and storage.
| xnx wrote:
| Is Google Cloud SQL a more direct alternative to Aurora? I'm
| having a hard time keeping all these database services
| straight.
| grrywlsn wrote:
| Cloud SQL is RDS; AlloyDB is Aurora.
| Keyframe wrote:
| on steroids it seems
| jerryjerryjerry wrote:
| Architecturally yes but with an extension of in-memory columnar
| format as well. This makes it an HTAP (Hybid Transactional and
| Analytical Processing) database.
___________________________________________________________________
(page generated 2023-08-29 23:02 UTC)