Debunking 6 common pgvector myths
Pgvector is Postgres' highly popular extension for storing, indexing and querying vectors. Vectors have been a useful data type for a long time, but recently they've seen rise in popularity due to their usefulness in RAG (Retrieval Augmented Generation) architectures of AI-based applications. Vectors typically power the retrieval part - using vector similarity search and nearest-neighbor algorithms, one can find the most relevant documents for a given user question.
Having the ability to store vectors in your normal relational database, as opposed to a dedicated vector store, means that you can use all the normal relational database capabilities together with vector search - join vector tables with other data and metadata, use additional fields for filtering, retrieve related information and so on.
Nile has supported pg_vector since our first private beta release, about a year ago. From conversations with both our users and in the pgvector community, it became clear that there are some common misconceptions and misunderstandings around its best practices and use. As a result of these misunderstandings, some people avoid pg_vector completely or use it less effectively than they otherwise would. So, let's fix this!
