Skip to main content
Context7 stores every library’s embeddings in a vector store and searches it on each query. The store is chosen independently of the relational database, so you can keep configuration and metadata in one place and send vectors somewhere else (“bring your own store”). This page covers the three backends and how to configure each.
Most single-container deployments need nothing here. The default embedded store works out of the box. You only need to change the vector store to run multiple replicas or to reuse a vector database you already operate.

​
Options

The embedded LanceDB index is local to one container, so it cannot back multiple replicas. To scale out you need a shared store: pgvector or Milvus.

​
Selecting a store

VECTOR_STORE picks the backend: With auto, setting DATABASE_URL to a Postgres connection (the multi-replica setup) automatically stores vectors in pgvector in that same database. You only set VECTOR_STORE explicitly to override that, for example to keep vectors in Milvus while the relational data lives in Postgres.

​
Postgres without pgvector

You can run the relational store on an external PostgreSQL and keep embeddings in the embedded index by setting VECTOR_STORE=lancedb alongside DATABASE_URL. Because only the pgvector backend creates the extension, a database used purely for relational data does not need pgvector, and the application user needs no more than normal table privileges.
The embedded index is local to one container, so this pairing suits a single-container deployment that wants its configuration and metadata in a managed database. For multiple replicas, vectors must go to a shared store: pgvector or Milvus.
Whatever the store, the collection or table is created on first write, the vector dimension is taken from your embedding model, and search uses an HNSW index with cosine similarity. There is no manual schema setup, and switching embedding models is a re-index rather than a migration.

​
pgvector

pgvector stores embeddings in PostgreSQL alongside (or beside) your relational data. In the standard multi-replica setup vectors share the relational database, so there is nothing extra to configure. See Scaling for the full provisioning guide, including managed Postgres (RDS, Cloud SQL, Azure) and self-hosted.
Use VECTOR_DATABASE_URL when you want vectors in a dedicated pgvector instance, for example to size and scale vector storage independently of the relational database.

​
Milvus

Set VECTOR_STORE=milvus to store embeddings in an external Milvus cluster or Zilliz Cloud. Context7 creates its collections (HNSW, cosine) on first write. Milvus 2.4 or newer is required. Use MILVUS_TOKEN for Zilliz Cloud and API-key clusters, or MILVUS_USERNAME + MILVUS_PASSWORD for a self-hosted cluster with username/password auth.
Take the public endpoint and API key from your Zilliz Cloud cluster, then set:
Milvus stores text and metadata as VARCHAR, capped at 65,535 characters. This is well above normal chunk sizes, but an unusually large single chunk will be rejected on insert.

​
Which one to use

  • Single container: keep the default (LanceDB). No configuration, no external service.
  • Multiple replicas, no existing vector database: use pgvector. Vectors share the PostgreSQL you already need for scaling, so there is nothing extra to run.
  • You already run Milvus or Zilliz Cloud, or you need a very large index managed separately from Postgres: use Milvus.