> ## Documentation Index > Fetch the complete documentation index at: https://docs.cognee.ai/llms.txt > Use this file to discover all available pages before exploring further. # Vector Stores > Configure vector databases for embedding storage and semantic search in Cognee 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](./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 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. ```dotenv theme={null} VECTOR_DB_PROVIDER="lancedb" # Optional path or URL. Defaults to /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. ```dotenv theme={null} 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): ```dotenv theme={null} VECTOR_DB_PROVIDER="turso" VECTOR_DB_URL="/absolute/path/to/cognee.turso.db" ``` Remote Turso cloud: ```dotenv theme={null} 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. ```dotenv theme={null} VECTOR_DB_PROVIDER="neptune_analytics" VECTOR_DB_URL="neptune-graph://" ``` AWS credentials are resolved through the environment or the default AWS SDK chain. Use this shape for ChromaDB. ```dotenv theme={null} 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` ```dotenv theme={null} VECTOR_DB_PROVIDER="qdrant" VECTOR_DB_URL="http://localhost:6333" VECTOR_DB_KEY="" ``` Use this shape for FalkorDB: ```dotenv theme={null} 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. ```dotenv theme={null} 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 is file-based and requires no additional setup. It's perfect for local development and single-user scenarios. ```dotenv theme={null} VECTOR_DB_PROVIDER="lancedb" # Optional, can be a path or URL. Defaults to /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 stores vectors inside your Postgres database using the pgvector extension. ```dotenv theme={null} 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: ```bash theme={null} pip install "cognee[postgres]" # or for binary version pip install "cognee[postgres-binary]" ``` **Docker Setup**: Use the built-in Postgres with pgvector: ```bash theme={null} 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](/setup-configuration/relational-databases#neon-postgres), 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 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): ```dotenv theme={null} VECTOR_DB_PROVIDER="turso" VECTOR_DB_URL="/absolute/path/to/cognee.turso.db" ``` Remote Turso cloud: ```dotenv theme={null} VECTOR_DB_PROVIDER="turso" VECTOR_DB_URL="libsql://your-db.turso.io" VECTOR_DB_KEY="your_turso_auth_token" ``` **Installation**: Install the Turso extra: ```bash theme={null} 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 `/databases/{user_id}/`. Deleting a dataset evicts its cached engine and removes that file. Qdrant requires a running instance of the Qdrant server. ```dotenv theme={null} VECTOR_DB_PROVIDER="qdrant" VECTOR_DB_URL="http://localhost:6333" ``` **Installation**: Since Qdrant is a community adapter, you have to install the community package: ```bash theme={null} pip install cognee-community-vector-adapter-qdrant ``` **Configuration**: To make sure Cognee uses Qdrant, you have to register it beforehand with the following line: ```python theme={null} from cognee_community_vector_adapter_qdrant import register register() ``` For more details on setting up Qdrant, visit the [more detailed description](/setup-configuration/community-maintained/qdrant) of this adapter. **Docker Setup**: Start the Qdrant service: ```bash theme={null} 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 can be used as a vector store through the Redis Search module, providing fast vector similarity search capabilities. ```dotenv theme={null} 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: ```bash theme={null} pip install cognee-community-vector-adapter-redis ``` **Configuration**: To make sure Cognee uses Redis, you have to register it beforehand with the following line: ```python theme={null} from cognee_community_vector_adapter_redis import register register() ``` You can also configure Redis programmatically: ```python theme={null} 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](/setup-configuration/community-maintained/redis) of this adapter. **Docker Setup**: Start a Redis instance with Search module enabled: ```bash theme={null} docker run -d --name redis -p 6379:6379 redis:8.0.2 ``` Or use **Redis Cloud** with the Search module enabled: [Redis Cloud](https://redis.io/try-free) **Connection URL Examples**: * Local: `redis://localhost:6379` * With authentication: `redis://user:password@localhost:6379` * With SSL: `rediss://localhost:6380` ChromaDB support is optional and may not be installed in your Cognee environment by default. ```dotenv theme={null} 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`: ```bash theme={null} 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: ```bash theme={null} docker run -p 8000:8000 chromadb/chroma ``` FalkorDB can serve as both graph and vector store, providing a hybrid solution. ```dotenv theme={null} 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: ```bash theme={null} pip install cognee-community-hybrid-adapter-falkor ``` **Configuration**: To make sure Cognee uses FalkorDB, you have to register it beforehand with the following line: ```python theme={null} from cognee_community_hybrid_adapter_falkor import register register() ``` For more details on setting up FalkorDB, visit the [more detailed description](/setup-configuration/community-maintained/falkordb) of this adapter. **Docker Setup**: Start the FalkorDB service: ```bash theme={null} docker run -p 6379:6379 -p 3000:3000 -it --rm falkordb/falkordb:edge ``` **Access**: Default ports are 6379 (DB) and 3000 (UI). Use Amazon Neptune Analytics as a hybrid vector + graph backend. ```dotenv theme={null} VECTOR_DB_PROVIDER="neptune_analytics" VECTOR_DB_URL="neptune-graph://" # AWS credentials via environment or default SDK chain ``` **Installation**: Install Neptune extras: ```bash theme={null} 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 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 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](/setup-configuration/graph-stores) | | `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](/setup-configuration/graph-stores), 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 | 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 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: ```text theme={null} 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: ```dotenv theme={null} VECTOR_DB_SUBPROCESS_ENABLED=false ``` And raise the shell limit before starting Cognee: ```bash theme={null} 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. 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](/setup-configuration/community-maintained/qdrant)** — Vector search engine with cloud and self-hosted options * **[Redis](/setup-configuration/community-maintained/redis)** — Fast vector similarity search * **[FalkorDB](/setup-configuration/community-maintained/falkordb)** — Hybrid vector and graph store * **[Pinecone](/setup-configuration/community-maintained/pinecone)** — Managed vector database (requires separate install + registration) * **[Turbopuffer](/setup-configuration/community-maintained/turbopuffer)** — High-performance vector database * **Milvus, Weaviate, and more** — See [all community adapters](/setup-configuration/community-maintained/overview) ## 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 Configure embedding providers for vector generation Set up graph databases for knowledge graphs Return to setup configuration overview