NetworkX
has already been migrated and the remaining adapters will follow shortly.
Therefore all new adapter contributions must target the community repository.packages/<engine_name>/cognee_community_graph_adapter_<engine_name>/
__init__.py
, <engine_name>_adapter.py
, and register.py
(see the Redis example).packages/<engine_name>/
add __init__.py
, pyproject.toml
, and README.md
.cognee-community
is the extension hub for Cognee.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
packages/*
in the community repo—each sub-folder represents a separate provider implemented in exactly the way you are about to do.
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:
GraphDBInterface
. Reference the KuzuAdapter or the Neo4jAdapter for a more comprehensive example.
File: packages/graph/engine_name/examples/example.pyCreate a script that loads cognee and the integration package, registers it to use your new
<engine_name>
provider, and runs basic usage checks (e.g., adding data, searching, pruning). For example:
File: .github/workflows/engine_name/test_engine_name.ymlCreate 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.
<engine_name>
appropriately.pyproject.toml
has an extras entry for any new dependencies.pyproject.toml
:
<EngineName>Adapter
in packages/<engine_name>/cognee_community_graph_adapter_<engine_name>/<engine_name>_adapter.py
.
register.py
) and call it before configuring Cognee:
example.py
.
.github/workflows/engine_name/test_<engine_name>.yml
.
pyproject.toml
extras.