Vector Stores

Vector stores hold embeddings for semantic similarity search. They enable Cognee to find conceptually related content based on meaning rather than exact text matches.

New to configuration?See the Setup Configuration Overview for the complete workflow:install extras → create .env → choose providers → handle pruning.

Supported Providers

Cognee supports multiple vector store options through built-in providers and community-maintained adapters:

Provider	Status	Notes
LanceDB	Built-in, default	File-based vector store, works out of the box
PGVector	Built-in extra	Postgres-backed vector storage with pgvector extension
Turso (libSQL)	Built-in extra	libSQL vector store; embedded local file or remote Turso cloud
Neptune Analytics	Built-in extra	Amazon Neptune Analytics hybrid solution
ChromaDB	Optional extra / adapter	HTTP server-based vector database; may require installing extra support
Qdrant	Community adapter	High-performance vector database and similarity search engine
Redis	Community adapter	Fast vector similarity search via Redis Search module
FalkorDB	Community adapter	Hybrid graph + vector database

Configuration

Environment Variables

Community adapters must still be installed and registered in your application startup code before Cognee can use their provider value.

Use this shape for LanceDB.

VECTOR_DB_PROVIDER="lancedb"
# Optional path or URL. Defaults to <SYSTEM_ROOT_DIRECTORY>/databases/cognee.lancedb
VECTOR_DB_URL="/absolute/or/relative/path/to/cognee.lancedb"
# Optional. Defaults to true.
VECTOR_DB_SUBPROCESS_ENABLED="true"
# Optional. Max concurrent async RPCs in flight per subprocess worker.
# Defaults to 16. Must be > 0 (worker init raises ValueError otherwise).
SUBPROCESS_WORKER_MAX_INFLIGHT="16"

Use this shape for PGVector.

VECTOR_DB_PROVIDER="pgvector"
VECTOR_DB_HOST="localhost"
VECTOR_DB_PORT="5432"
VECTOR_DB_NAME="cognee_db"
VECTOR_DB_USERNAME="cognee"
VECTOR_DB_PASSWORD="cognee"
# Optional SQLAlchemy pool args JSON.
VECTOR_POOL_ARGS='{"pool_size": 2, "max_overflow": 2}'

If the explicit VECTOR_DB_* Postgres values are omitted, Cognee falls back to the relational DB_HOST, DB_PORT, DB_NAME, DB_USERNAME, and DB_PASSWORD settings. When backend access control is enabled, configure the explicit VECTOR_DB_* values.

Use this shape for Turso / libSQL. One adapter handles both modes.Embedded (local file):

VECTOR_DB_PROVIDER="turso"
VECTOR_DB_URL="/absolute/path/to/cognee.turso.db"

Remote Turso cloud:

VECTOR_DB_PROVIDER="turso"
VECTOR_DB_URL="libsql://your-db.turso.io"
VECTOR_DB_KEY="your_turso_auth_token"

A URL scheme of libsql://, http(s)://, or ws(s):// is treated as a remote server (auth token sent via VECTOR_DB_KEY); any other value is treated as a local embedded file path. Requires the cognee[turso] extra.

Use this shape for Neptune Analytics.

VECTOR_DB_PROVIDER="neptune_analytics"
VECTOR_DB_URL="neptune-graph://<GRAPH_ID>"

AWS credentials are resolved through the environment or the default AWS SDK chain.

Use this shape for ChromaDB.

VECTOR_DB_PROVIDER="chromadb"
VECTOR_DB_URL="http://localhost:8000"
VECTOR_DB_KEY=""

ChromaDB support may require installing the optional extra or adapter before setting VECTOR_DB_PROVIDER="chromadb".

Use this shape for community adapters that connect through a URL.Provider values:

qdrant
redis
pinecone
falkor

VECTOR_DB_PROVIDER="qdrant"
VECTOR_DB_URL="http://localhost:6333"
VECTOR_DB_KEY=""

Use this shape for FalkorDB:

VECTOR_DB_PROVIDER="falkor"
VECTOR_DB_URL="localhost"
VECTOR_DB_PORT="6379"

GRAPH_DATABASE_PROVIDER="falkor"
GRAPH_DATABASE_URL="localhost"
GRAPH_DATABASE_PORT="6379"

Use VECTOR_DB_KEY for Qdrant Cloud, Pinecone, or other authenticated deployments. Redis usually puts credentials in the URL. FalkorDB also needs VECTOR_DB_PORT, and hybrid graph + vector setups need the matching GRAPH_DATABASE_* variables.

Use this shape for Turbopuffer.

TURBOPUFFER_API_KEY="your_api_key"
VECTOR_DATASET_DATABASE_HANDLER="turbopuffer"
# Optional: defaults to gcp-us-central1
TURBOPUFFER_REGION="gcp-us-central1"

This adapter uses custom TURBOPUFFER_* environment variables instead of the normal VECTOR_DB_URL / VECTOR_DB_KEY shape.

Setup Guides

LanceDB (Default)

LanceDB is file-based and requires no additional setup. It’s perfect for local development and single-user scenarios.

VECTOR_DB_PROVIDER="lancedb"
# Optional, can be a path or URL. Defaults to <SYSTEM_ROOT_DIRECTORY>/databases/cognee.lancedb
# VECTOR_DB_URL=/absolute/or/relative/path/to/cognee.lancedb

Installation: LanceDB is included by default with Cognee. No additional installation required.Data Location: Vectors are stored in a local directory. Defaults under the Cognee system path if VECTOR_DB_URL is empty.

PGVector

PGVector stores vectors inside your Postgres database using the pgvector extension.

VECTOR_DB_PROVIDER="pgvector"
# If these are omitted, Cognee falls back to the relational DB settings
# (DB_HOST, DB_PORT, DB_NAME, DB_USERNAME, DB_PASSWORD).
VECTOR_DB_HOST="localhost"
VECTOR_DB_PORT="5432"
VECTOR_DB_NAME="cognee_db"
VECTOR_DB_USERNAME="cognee"
VECTOR_DB_PASSWORD="cognee"

Installation: Install the Postgres extras:

pip install "cognee[postgres]"
# or for binary version
pip install "cognee[postgres-binary]"

Docker Setup: Use the built-in Postgres with pgvector:

docker compose --profile postgres up -d

Note: If using your own Postgres, ensure CREATE EXTENSION IF NOT EXISTS vector; is available in the target database.For Neon Postgres, run that extension statement once in the Neon database where Cognee stores vectors. Neon still uses the regular Cognee pgvector provider; configure the relational DB_* values and DATABASE_CONNECT_ARGS as described in Relational Databases, then set VECTOR_DB_PROVIDER="pgvector".When backend access control is enabled, configure the explicit VECTOR_DB_HOST, VECTOR_DB_PORT, VECTOR_DB_NAME, VECTOR_DB_USERNAME, and VECTOR_DB_PASSWORD values instead of relying on the relational DB fallback.

Turso (libSQL)

Turso stores vectors in libSQL. The same adapter works either embedded (a local .turso.db file) or against a remote Turso cloud database.Embedded (local file):

VECTOR_DB_PROVIDER="turso"
VECTOR_DB_URL="/absolute/path/to/cognee.turso.db"

Remote Turso cloud:

VECTOR_DB_PROVIDER="turso"
VECTOR_DB_URL="libsql://your-db.turso.io"
VECTOR_DB_KEY="your_turso_auth_token"

Installation: Install the Turso extra:

pip install "cognee[turso]"

This pulls in libsql-experimental. If the extra is missing, selecting VECTOR_DB_PROVIDER="turso" raises an ImportError at engine creation with the install hint.URL detection: A libsql://, http(s)://, or ws(s):// URL connects to a remote libSQL server (using VECTOR_DB_KEY as the auth token). Any other value is treated as a local embedded file path.Multi-user mode: Setting VECTOR_DB_PROVIDER="turso" automatically selects the turso dataset database handler (you do not need to set VECTOR_DATASET_DATABASE_HANDLER yourself). With ENABLE_BACKEND_ACCESS_CONTROL=True, each dataset gets its own embedded libSQL file named {dataset_id}.turso.db under <SYSTEM_ROOT_DIRECTORY>/databases/{user_id}/. Deleting a dataset evicts its cached engine and removes that file.

Qdrant

Qdrant requires a running instance of the Qdrant server.

VECTOR_DB_PROVIDER="qdrant"
VECTOR_DB_URL="http://localhost:6333"

Installation: Since Qdrant is a community adapter, you have to install the community package:

pip install cognee-community-vector-adapter-qdrant

Configuration: To make sure Cognee uses Qdrant, you have to register it beforehand with the following line:

from cognee_community_vector_adapter_qdrant import register

register()

For more details on setting up Qdrant, visit the more detailed description of this adapter.Docker Setup: Start the Qdrant service:

docker run -p 6333:6333 -p 6334:6334 \
    -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \
    qdrant/qdrant

Access: Default port is 6333 for the database, and you can access the Qdrant dashboard at “localhost:6333/dashboard”.

Redis

Redis can be used as a vector store through the Redis Search module, providing fast vector similarity search capabilities.

VECTOR_DB_PROVIDER="redis"
VECTOR_DB_URL="redis://localhost:6379"
# VECTOR_DB_KEY is optional and not used by Redis

Installation: Since Redis is a community adapter, you have to install the community package:

pip install cognee-community-vector-adapter-redis

Configuration: To make sure Cognee uses Redis, you have to register it beforehand with the following line:

from cognee_community_vector_adapter_redis import register

register()

You can also configure Redis programmatically:

from cognee import config

config.set_vector_db_config({
    "vector_db_provider": "redis",
    "vector_db_url": "redis://localhost:6379",
})

For more details on setting up Redis, visit the more detailed description of this adapter.Docker Setup: Start a Redis instance with Search module enabled:

docker run -d --name redis -p 6379:6379 redis:8.0.2

Or use Redis Cloud with the Search module enabled: Redis CloudConnection URL Examples:

Local: redis://localhost:6379
With authentication: redis://user:password@localhost:6379
With SSL: rediss://localhost:6380

ChromaDB

ChromaDB support is optional and may not be installed in your Cognee environment by default.

VECTOR_DB_PROVIDER="chromadb"
VECTOR_DB_URL="http://localhost:8000"
VECTOR_DB_KEY=""
# ChromaDB does not currently support Cognee backend access control dataset routing.
ENABLE_BACKEND_ACCESS_CONTROL="False"

Installation: Install ChromaDB support before configuring VECTOR_DB_PROVIDER=chromadb:

pip install "cognee[chromadb]"

If you are using ChromaDB through a community adapter package instead of a Cognee extra, install that adapter package and call its register() function before running Cognee vector operations.Docker Setup: Start a ChromaDB server:

docker run -p 8000:8000 chromadb/chroma

FalkorDB

FalkorDB can serve as both graph and vector store, providing a hybrid solution.

VECTOR_DB_PROVIDER="falkor"
VECTOR_DB_URL="localhost"
VECTOR_DB_PORT="6379"

Installation: Since FalkorDB is a community adapter, you have to install the community package:

pip install cognee-community-hybrid-adapter-falkor

Configuration: To make sure Cognee uses FalkorDB, you have to register it beforehand with the following line:

from cognee_community_hybrid_adapter_falkor import register

register()

For more details on setting up FalkorDB, visit the more detailed description of this adapter.Docker Setup: Start the FalkorDB service:

docker run -p 6379:6379 -p 3000:3000 -it --rm falkordb/falkordb:edge

Access: Default ports are 6379 (DB) and 3000 (UI).

Neptune Analytics

Use Amazon Neptune Analytics as a hybrid vector + graph backend.

VECTOR_DB_PROVIDER="neptune_analytics"
VECTOR_DB_URL="neptune-graph://<GRAPH_ID>"
# AWS credentials via environment or default SDK chain

Installation: Install Neptune extras:

pip install "cognee[neptune]"

Note: URL must start with neptune-graph:// and AWS credentials should be configured via environment variables or AWS SDK.

Important Considerations

Dimension Consistency

Ensure EMBEDDING_DIMENSIONS matches your vector store collection/table schemas:

PGVector column size
LanceDB Vector size
ChromaDB collection schema

Changing dimensions requires recreating collections.

PGVector table layout (where embeddings are stored)

PGVector does not use a single embeddings table. Cognee creates one table per indexed field, named {DataPointType}_{field} — for example DocumentChunk_text, Entity_name, EntityType_name, and TextSummary_text. Each of these collection tables has exactly three columns:

Column	Type	Description
`id`	`uuid` (primary key)	Matches the corresponding node id in the graph store
`payload`	`json`	Serialized data point — includes the embedded `text` plus reference scalars such as `document_id`, `document_name`, `chunk_index`, `source_chunk_id`, and `belongs_to_set`
`vector`	`vector(N)`	The embedding itself; `N` is your `EMBEDDING_DIMENSIONS` / model vector size

When PGVector shares the relational Postgres database, these collection tables live in the same schema as the snake_case relational metadata and provenance tables (data, datasets, dataset_data, nodes, and edges). If you configure PGVector with separate VECTOR_DB_* settings, the collection tables live in that vector database instead. When using the Postgres graph store, graph data is stored in graph_node and graph_edge.Cognee distinguishes vector collections by their PascalCase first letter. Text content is stored in the JSON payload and in TEXT columns; there are no fixed-width varchar(255) columns (the relational provenance nodes.label / nodes.type columns were migrated from varchar(255) to TEXT).

Provider Comparison

Provider	Setup	Performance	Use Case
LanceDB	Zero setup	Good	Local development
PGVector	Postgres required	Excellent	Production with Postgres
Turso (libSQL)	`cognee[turso]` extra	Good	Embedded local file or remote Turso cloud
Neptune Analytics	AWS required	Excellent	Cloud hybrid solution
ChromaDB	Server required	Good	Dedicated vector store
Qdrant	Server required	Excellent	High-performance vector search
Redis	Server required	Excellent	Low-latency in-memory search
FalkorDB	Server required	Good	Hybrid graph + vector

Troubleshooting

Too many open files on macOS

This issue is most commonly reported with LanceDB-backed search workloads.VECTOR_DB_SUBPROCESS_ENABLED defaults to true. In high-fanout searches — for example, many queries across many datasets — this can create a large number of OS subprocesses. On macOS, that can quickly hit the default file descriptor limit (ulimit -n, often 256) and surface as:

OSError: [Errno 24] Too many open files

Because the exception often appears inside LanceDB internals, it may not be obvious that the underlying issue is subprocess and file-descriptor exhaustion rather than a LanceDB data problem.If this happens:

VECTOR_DB_SUBPROCESS_ENABLED=false

And raise the shell limit before starting Cognee:

ulimit -n 4096

This is especially relevant for audit-style or multi-dataset search runs where Cognee fans queries out across several datasets in parallel.

Subprocess concurrency and per-call failures

When VECTOR_DB_SUBPROCESS_ENABLED is true, concurrent async RPCs to the LanceDB subprocess run in parallel rather than serializing behind a single session lock. Each request carries its own id and is routed back to its own waiter, so concurrent add and search operations no longer queue behind one another.SUBPROCESS_WORKER_MAX_INFLIGHT (default 16) bounds how many async operations a worker runs at once, keeping the worker’s memory footprint predictable. The value must be > 0; a zero or negative value fails worker initialization with a ValueError rather than silently degrading. Raise it for higher concurrency (for example, SUBPROCESS_WORKER_MAX_INFLIGHT=64), or set a large value to effectively remove the cap.A per-call timeout or cancellation now resolves only that individual call and leaves the subprocess session running for other in-flight and future calls. The session is torn down only on genuine session-ending events (worker crash, shutdown, or respawn), which propagate a SubprocessTransportError to any calls still pending. Synchronous calls (such as the Kuzu graph backend) are unaffected and continue to run serially.

Community-Maintained Providers

Additional vector stores are available through community-maintained adapters:

Qdrant — Vector search engine with cloud and self-hosted options
Redis — Fast vector similarity search
FalkorDB — Hybrid vector and graph store
Pinecone — Managed vector database (requires separate install + registration)
Turbopuffer — High-performance vector database
Milvus, Weaviate, and more — See all community adapters

Notes

Embedding Integration: Vector stores use your embedding engine from the Embeddings section
Dimension Matching: Keep EMBEDDING_DIMENSIONS consistent between embedding provider and vector store
Performance: Local providers (LanceDB) are simpler but cloud providers offer better scalability

Embedding Providers

Configure embedding providers for vector generation

Graph Stores

Set up graph databases for knowledge graphs

Overview

Return to setup configuration overview

Getting Started

Core Concepts

Setup Configuration

Guides

Examples

CLI

Rust SDK

TypeScript SDK

OSS

Supported Providers

Configuration

Setup Guides

Important Considerations

Troubleshooting

Community-Maintained Providers

Notes

Embedding Providers

Graph Stores

Overview

​Supported Providers

​Configuration

​Setup Guides

​Important Considerations

​Troubleshooting

​Community-Maintained Providers

​Notes

Embedding Providers

Graph Stores

Overview

Supported Providers

Configuration

Setup Guides

Important Considerations

Troubleshooting

Community-Maintained Providers

Notes