Vector Library versus Vector Database

In the world of Vector Search, we use vector embeddings – generated by Machine Learning models – to represent data objects (text, images, audio, etc.). The key idea here is that embeddings that are semantically similar to each other have a smaller distance between them.
We can use vector distance functions like euclidean distance or cosine distance to determine if these objects are similar to other objects in the collection. However, to do this we need to compare the distances between the query vector and every vector in the collection. This type of calculation can be difficult to scale to millions or billions of vectors.
This is why we have Vector Databases and Vector Libraries. They both use the Approximate Nearest Neighbor (ANN) algorithm to search through vectors in a tiny fraction of the time. You can learn more about this topic from "Why Vectors Search is so Fast."
The Big Question
So, if both vector databases and vector libraries allow you to efficiently search through your vectors. What are the key differences between them, and why/when should you choose one over the other?
Vector Libraries
Vector libraries store vector embeddings in in-memory indexes, in order to perform similarity search. Most vector libraries share the following characteristics:
- they store vectors only,
- index data is immutable,
- query during import limitation
Store Vectors Only
Vector libraries only store vector embeddings and not the associated objects they were generated from.
When you run a query, a vector library will respond with the relevant vectors and object ids. This is limiting since the actual information is stored in the object and not the id. To solve this problem, you would need to store the objects in a secondary storage. You can then use the returned ids from the query and match them to the objects to understand the results.
Immutable Data
Indexes produced by vector libraries are immutable. This means that once you have imported your data and built the index, you cannot make any modifications (no new inserts, deletes or changes). To make any changes to your index, you will need to rebuild it from scratch.
Query during Import Limitation
Most vector libraries cannot be queried while importing your data. It is required to import all of your data objects first. Then the index is built after the objects have been imported. This can be a concern for applications that require importing millions or even billions of objects.
Examples of Vector Libraries
There are quite a few libraries to choose from - Facebook Faiss, Spotify Annoy, Google ScaNN, NMSLIB, and HNSWLIB. These libraries enable users to perform vector similarity search using the ANN algorithm.
The ANN algorithm has different implementations depending on the vector library. Faiss uses the clustering method, Annoy uses trees, and ScaNN uses vector compression. There is a performance tradeoff for each, which you can choose depending on your application and performance measure.
Example Use Cases
Vector libraries are commonly used for applications that do not have changing data. For example, academic information retrieval benchmarks are designed to test performance on a static snapshot of data. When plugging an ANN index into production-ready applications, databases offer many appealing features not found in a library.
Vector Databases
One of the core features that set vector databases apart from libraries is the ability to store and update your data. Vector databases have full CRUD (create, read, update, and delete) support that solves the limitations of a vector library. Additionally, databases are more focused on enterprise-level production deployments.