TensorChord

Why is Postgres well-suited (or even the best choice) for apps using vector similarity search? Similarity search alone is insufficient for general-purpose apps that typically filter data using several columns/fields. Pure vector databases address this requirement by allowing you to add text/numeric metadata to vectors and pre-filter by the metadata before initiating the computationally intensive vector similarity search. This pre-filtering capability has existed in Postgres since its inception. You pre-filter by specifying a condition on non-vector columns in the WHERE clause of a query statement. :) For instance, imagine a user selecting the `Science Fiction` category and asking to suggest movies with a rating of 7 or higher. Then, the user prompts for `A movie about a space adventure`. The final SQL query might look as shown in the picture. The data is initially filtered by the vote_average (rank from 1 through 10) and genres (an array of JSON objects) columns, followed by the similarity search on the overview_vector column.

pgvector is the de facto standard for vectorized processing in Postgres. But its dominance can be challenged soon by pgvecto.rs - a Postgres extension for vector similarity search written in Rust. The extension is still in beta, but its capabilities already look compelling. github.com/tensorchord/pgvec… – at Florida, USA