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#
| Store | Best for | Runs where | Configuration |
|---|---|---|---|
| LanceDB (default) | Single container | Embedded in the container's data volume | None |
| pgvector | Multiple replicas, already running PostgreSQL | Your PostgreSQL, the same database as the relational data or a separate one | DATABASE_URL or VECTOR_DATABASE_URL |
| Milvus | Multiple replicas with an existing Milvus / Zilliz Cloud, or very large indexes | An external Milvus cluster or Zilliz Cloud | MILVUS_* |
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:
| Value | Behavior |
|---|---|
auto (default) | pgvector when a PostgreSQL URL is available for vectors, otherwise embedded LanceDB. |
lancedb | Embedded local index. |
pgvector | pgvector in PostgreSQL. Requires a Postgres VECTOR_DATABASE_URL (or DATABASE_URL). |
milvus | External Milvus or Zilliz Cloud. Requires MILVUS_ADDRESS. |
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.
| Variable | Description |
|---|---|
VECTOR_DATABASE_URL | PostgreSQL DSN for vectors. Defaults to DATABASE_URL, so vectors share the relational database. Set it to point vectors at a separate pgvector service. The target needs the pgvector extension. |
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.
| Variable | Required | Description |
|---|---|---|
MILVUS_ADDRESS | Yes | Cluster endpoint, for example milvus:19530 or https://your-cluster.zillizcloud.com. |
MILVUS_TOKEN | API-key authentication, used by Zilliz Cloud and token-secured clusters. | |
MILVUS_USERNAME | Username for a self-hosted cluster with user/password auth. | |
MILVUS_PASSWORD | Password to go with MILVUS_USERNAME. | |
MILVUS_DATABASE | Milvus database name. Defaults to the server default. |
Use MILVUS_TOKEN for Zilliz Cloud and API-key clusters, or MILVUS_USERNAME + MILVUS_PASSWORD for a self-hosted cluster with username/password auth.
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.