[HN Gopher] Vector databases: analyzing the trade-offs
       ___________________________________________________________________
        
       Vector databases: analyzing the trade-offs
        
       Author : chop
       Score  : 45 points
       Date   : 2023-08-19 21:46 UTC (1 days ago)
        
 (HTM) web link (thedataquarry.com)
 (TXT) w3m dump (thedataquarry.com)
        
       | mark_l_watson wrote:
       | For use with LLMs, I implemented my own vector DB code in Common
       | Lisp and Swift.
       | 
       | When I work in Python, my favorite is absolutely Chroma embedded.
       | 
       | The article is wrong about Chroma embedded being in memory only.
       | It also works fine with write through to a local disk, including
       | maintaining index files.
        
         | fzliu wrote:
         | Shameless self-plug for our embedded vector database milvus-
         | lite (https://github.com/milvus-io/milvus-lite):
         | pip install milvus
        
       | hnrj95 wrote:
       | surprised there's no mention of kdb+ in here. iirc it's older and
       | more performant than most of these
        
         | WillDaSilva wrote:
         | kdb doesn't support effecient vector similarity searches, or
         | efficient storage of high-dimensional vectors. It isn't really
         | in the same class as the vector databases discussed in this
         | post. It's more suited for time series data.
        
       | dmezzetti wrote:
       | Adding txtai to the list: https://github.com/neuml/txtai
       | 
       | txtai is an all-in-one embeddings database for semantic search,
       | LLM orchestration and language model workflows.
       | 
       | Embeddings databases are a union of vector indexes (sparse and
       | dense), graph networks and relational databases. This enables
       | vector search with SQL, topic modeling and retrieval augmented
       | generation.
       | 
       | txtai adopts a local-first approach. A production-ready instance
       | can be run locally within a single Python instance. It can also
       | scale out when needed.
        
         | simonw wrote:
         | What are the benefits of a dedicated embeddings database over
         | adding a vector index to an existing engine, like sqlite-vss or
         | pg_vector or Elasticsearch?
         | 
         | Vector search still feels like more of an index type feature
         | than a separate product to me.
        
           | dmezzetti wrote:
           | pg_vector doesn't perform well compared to other methods, at
           | least according to ANN-Benchmarks (https://ann-
           | benchmarks.com/).
           | 
           | txtai is more than just a vector database. It also has a
           | built-in graph component for topic modeling that utilizes the
           | vector index to autogenerate relationships. It can store
           | metadata in SQLite/DuckDB with support for other databases
           | coming. It has support for running LLM prompts right with the
           | data, similar to a stored procedure, through workflows. And
           | it has built-in support for vectorizing data into vectors.
           | 
           | For vector databases that simply store vectors, I agree that
           | it's nothing more than just a different index type.
        
           | convolvatron wrote:
           | communications cost. you certainly get cache coherency and
           | prefetching that you wouldn't get if you were following
           | pointer. in a distributed context that's a big hit.
        
           | whakim wrote:
           | pg_vector doesn't do nearly as well (relative to a dedicated
           | vector DB) in terms of speed and accuracy. That being said, I
           | think it's still clearly the correct choice in a lot of
           | cases. An order of magnitude speedup may not matter at all at
           | small or medium scale. And pg_vector (or something else) is
           | likely to continue to improve significantly. Contrast that
           | with the costs (in terms of time and money) of running
           | additional infrastructure.
        
       | gk1 wrote:
       | Full disclosure: I work for Pinecone, which is conspicuously
       | absent from the write-up despite being the first and most popular
       | vector database.
       | 
       | While it's great to see efforts to make sense of the (admittedly
       | noisy) vector database market, I'm struggling to grok large
       | chunks of this. For example I can't tell what the author means by
       | "serverless", but given that they put a whole bunch of open-
       | source, self-hosted solutions in that part of the diagram it's
       | definitely not the commmonly understood meaning.
       | 
       | For anyone diving into the topic, here is another introductory
       | article to help you: https://www.pinecone.io/learn/vector-
       | database/
        
         | dmezzetti wrote:
         | Pinecone is not absent and it's definitely not the first vector
         | database.
        
       ___________________________________________________________________
       (page generated 2023-08-20 23:00 UTC)