Skip to main content

Adding a New Graph Database to cognee

This guide describes how to integrate a new graph database engine into cognee.

Repository Options

Cognee used both the core and the community repositories to host graph-database adapters. 🚨 From now on every graph-database adapter – except Kuzu – will live in the cognee-community repository. NetworkX has already been migrated and the remaining adapters will follow shortly. Therefore all new adapter contributions must target the community repository.
The core repository will keep only the built-in Kuzu integration.

For Community Repository

To add a new adapter to cognee-community:
  1. Fork and clone the cognee-community repository
  2. Create your adapter in packages/<engine_name>/cognee_community_graph_adapter_<engine_name>/
  3. Inside that directory add __init__.py, <engine_name>_adapter.py, and register.py (see the Redis example).
  4. At the package root packages/<engine_name>/ add __init__.py, pyproject.toml, and README.md.
  5. Submit a pull request to the community repository
Below are the recommended steps in more detail.

Why cognee-community?

cognee-community is the extension hub for Cognee.
Anything that is not part of the core lives here—adapters for third-party databases, pipelines, community contributed additional tasks, etc.
Placing your adapter in this repository means:
  • Your code is released under the community license and can evolve independently of the core.
  • It can be installed with pip install cognee-community-graph-adapter-(engine_mane) without pulling in heavyweight drivers for users who don’t need them. For example, for NetworkX it is pip install cognee-community-graph-adapter-networkx
  • These packages can be called with cognee core package using the registration step described below.
If you are unfamiliar with the layout, have a look at the existing folders under packages/* in the community repo—each sub-folder represents a separate provider implemented in exactly the way you are about to do.

1. Implement the Adapter

File: packages/graph/<engine_name>/cognee_community_graph_adapter_<engine_name>/<engine_name>_adapter.py
Your adapter must subclass GraphDBInterface, implementing all required CRUD and utility methods (e.g., add_node, add_edge, extract_node, etc.). Here is a sample skeleton with placeholders:
Keep the method signatures consistent with GraphDBInterface. Reference the KuzuAdapter or the Neo4jAdapter for a more comprehensive example.
Adapter instance reuse: Cognee’s graph engine factory caches adapter instances keyed by their configuration parameters. Multiple calls with identical settings return the same adapter object. Design your adapter to be safe for reuse — avoid per-instance mutable state that cannot be safely shared, and prefer lazy or thread-safe initialization where state is required. When an entry is evicted (e.g. cache eviction or cache_clear), the factory calls your adapter’s close() — deferred until every leased reference to that instance is released — so implement close() idempotently; if it raises, the error is logged and swallowed rather than propagated to the caller.
Optional get_id_filtered_graph_data: This method is not part of GraphDBInterface, so it is optional. If you implement it, graph-completion searches project only the vector-search neighborhood instead of loading the full graph via get_graph_data(); if you omit it, Cognee falls back to get_graph_data(). The contract is edge-driven and matches the built-in Ladybug, Neo4j, and Postgres adapters: given target_ids, return (nodes, edges) where edges are every edge with either endpoint in target_ids, and nodes are all endpoint nodes of those edges (same (node_id, properties) / (source_id, target_id, relationship_label, properties) shapes as get_graph_data()). Return ([], []) when target_ids is empty; Cognee also falls back to the full graph if the filtered result comes back empty.
Declaring Cypher support: GraphDBInterface declares supports_cypher_queries: bool = True, so adapters are assumed to speak Cypher through query(). Override it to False on your adapter class when query() executes something else — the built-in Postgres and Turso adapters do this because their query() runs SQL against the graph tables. SearchType.CYPHER and SearchType.NATURAL_LANGUAGE then raise SearchTypeNotSupported (naming your adapter class) instead of handing your backend a Cypher string it cannot parse. Keep the flag on the class rather than setting it in __init__: tests and tooling read the capability directly off the adapter class without instantiating it (no database connection needed), as Cognee’s own adapter tests do.

2. Test with a Dedicated Script

Your contribution should have an example showcasing how this integration should be configured and used.
File: packages/graph/engine_name/examples/example.py
Create a script that loads cognee and the integration package, registers it to use your new <engine_name> provider, and runs basic usage checks (for example, remembering data, recalling it, and pruning isolated test state). For example:

3. Create a Test Workflow

File: .github/workflows/engine_name/test_engine_name.yml
Create a GitHub Actions workflow to run your integration tests. This ensures any pull requests that modify your new engine (or the shared graph code) will be tested automatically. See an example here.
Tips:
  • Rename <engine_name> appropriately.
  • Ensure your pyproject.toml has an extras entry for any new dependencies.

5. Poetry Extras

If your new graph engine requires a special Python client or system libraries, update: pyproject.toml:

6. Final Checklist

  1. Implement your <EngineName>Adapter in packages/<engine_name>/cognee_community_graph_adapter_<engine_name>/<engine_name>_adapter.py.
  2. Add a register helper (register.py) and call it before configuring Cognee:
  3. Create a test or example script example.py.
  4. Create a test workflow: .github/workflows/engine_name/test_<engine_name>.yml.
  5. Add required dependencies to pyproject.toml extras.
  6. Open a PR to verify that your new integration passes CI.
That’s all! This approach keeps cognee’s architecture flexible, allowing you to swap in any graph DB provider easily. Review the previous implementations in the core and the community repos.

Join the Conversation!

Have questions about creating custom tasks? Join our community to discuss implementation strategies and best practices!