Skip to main content

Core Responsibilities and Lifecycle

All handlers implement the DatasetDatabaseHandlerInterface, which defines three lifecycle entry points.
Handlers must implement the following methods:
  • create_dataset(dataset_id, user) -> dict Creates or resolves backing storage for the dataset and returns a dictionary of connection and identification fields. This may:
    • Provision new infrastructure (e.g., create a Neo4j Aura instance), or
    • Return connection details to an existing shared or pooled backend.
  • resolve_dataset_connection_info(dataset_database) -> DatasetDatabase (optional override) Converts stored references into runtime-ready connection details. Typical use cases include:
    • Decrypting stored secrets
    • Fetching short-lived access tokens The default implementation returns the input unchanged.
  • delete_dataset(dataset_database) -> None Deprovisions, deletes, or prunes the dataset’s backing storage.

Persisted Dataset Database Records

The dictionary returned from create_dataset() is persisted as a DatasetDatabase row in the relational database and later merged into runtime connection flows. Typical stored fields include:
  • vector_database_provider
  • vector_database_url
  • vector_database_key
  • vector_database_name
  • vector_dataset_database_handler
  • vector_database_connection_info (JSON dictionary for extended or sensitive parameters such as usernames, passwords, or custom options)
  • graph_database_provider
  • graph_database_url
  • graph_database_key
  • graph_database_name
  • graph_dataset_database_handler
  • graph_database_connection_info (JSON dictionary for extended or sensitive parameters such as usernames, passwords, or custom options)

Where Dataset Database Handlers Are Used

Handlers are invoked automatically by the system based on configuration.
  • Vector storage
    • Selected via VECTOR_DATASET_DATABASE_HANDLER environment variable
  • Graph storage
    • Selected via GRAPH_DATASET_DATABASE_HANDLER environment variable
When a dataset is accessed:
  • A new DatasetDatabase row is created if one does not already exist.
  • The handler name, provider, and connection metadata are stored for reuse.
  • At runtime, the handler may resolve secrets or transform stored references before connections are opened.
  • On dataset deletion, the handler is responsible for cleaning up the underlying storage. The dataset deletion call happens when pruning data in Cognee and when datasets are explicitly deleted.

List of Supported Dataset Database Handlers:

Core handlers included with Cognee:

  • neo4j_aura_dev → Neo4j Aura development cloud handler
  • kuzu → Kuzu graph handler
  • lancedb → LanceDB vector handler

Community-contributed handlers from the community repository:

  • qdrant → Qdrant vector handler using local docker
  • falkor_vector_local -> FalkorDB vector handler using local docker
  • falkor_graph_local -> FalkorDB graph handler using local docker

Using Custom Dataset Database Handlers

You can add your own at runtime with a register function, then point configuration to your handler name. For example:
By writing your own Dataset Database Handlers, you can integrate Cognee with any graph or vector storage backend while maintaining clean separation of concerns and secure handling of connection details. This extensibility allows Cognee to adapt to a wide range of deployment scenarios and infrastructure setups (AWS, GCP, Azure, Local and etc.).

Dataset Database Handler Interface

Below is the full interface definition that all Dataset Database Handlers must implement along with docstrings explaining each method and its purpose.