When to choose Vector Search versus other vector database options?

[JasonC]

I am designing a basic RAG application and reviewing vector database options for storing embeddings. Are there any functional differences between using Vector Search versus something like, Postgres on Cloud SQL with pgvector extensions enabled?

[pbalm]

Hi there, I would say that Vector Search and Postgresql+pgvector are functionally the same, the differences are what we would call "non-functional". There are differences in cost, espcially for small deployments. Vector Search is expensive, but supporting a heavy load with CloudSQL can get expensive too. Consider that with CloudSQL you will be in charge of monitoring your database cluster whereas with Vector Search, it can scale up and down automatically. When the number of queries on your database gets very high and/or the number of vectors that you store is very high, Vector Search will continue to deliver low latency and CloudSQL will start to suffer. Also consider that the Postgresql interface is more standard SQL than the interface of Vector Search. These are some examples of how they differ, but functionally, for vector functions at least, I would say they are the same 🙂

If you're considering CloudSQL (Postgresql with pgvector), make sure to take a look at AlloyDB as well, and for small applications, the vector functionality in Firestore might be attractive as well.

[JasonC]

This is excellent information, thank you!

[pbalm]

Actually one functional difference that occurred to me: In CloudSQL or AlloyDB in the end you store your embeddings in a regular table where one column contains the embeddings. If you wanted to have some metadata attached to each chunk that you want to filter on, then you can add this as a column. For example, imagine that each chunk comes from a document and the document can be either public, confidential, or top-secret. If a user has access to confidential information but not top-secret, then you can `SELECT` the embeddings `WHERE classification in ('public', 'confidential')` (sorry if I get the SQL syntax wrong but I hope you get the point). You would filter on the column "classification" that has the level of the document and get only the public and confidential ones if that's the access the user has. For example.

Vector Search uses a different mechanism for this, it works by attaching metadata to each chunk, as a set of labels, and then you would filter on those in your query. That achieves the same result but it works differently.