Skip to main content

​
cognee.prune

Static class with methods for cleaning up Cognee data and system state.

​
Methods

​
prune.prune_data()

Removes all raw data files from the file storage backend (local disk or S3, configured via DATA_ROOT_DIRECTORY). Does not remove database records — use prune_system(metadata=True) for that.

​
prune.prune_system()

Cleans up system database resources selectively. Does not delete files from storage — call prune_data() first if you also need to wipe raw files.
​
bool
default:"True"
Delete all data from the graph database (e.g., Kuzu, Neo4j).
​
bool
default:"True"
Delete all data from the vector store (e.g., LanceDB, Qdrant).
​
bool
default:"False"
Delete the relational metadata database (datasets, data records, pipeline state). Defaults to False to prevent accidental loss of metadata.
​
bool
default:"True"
Clear the cache. This wipes the cache directory (CACHE_ROOT_DIRECTORY — e.g. downloaded ontologies and tutorial data) and, when session caching or usage logging is enabled, also prunes the session cache backend (conversation history and usage logs). It does not touch graph, vector, or relational data.
prune_system has no permission checks and will wipe all graph and vector data regardless of which user or dataset it belongs to. Only use it in local development or test environments.
Prune cannot target a single dataset. Neither prune_data() nor prune_system() accepts a dataset_id — both always operate globally across every dataset. To remove a single dataset, use cognee.datasets.empty_dataset(dataset_id), which deletes that dataset’s graph content, data records, and the dataset entity itself while leaving other datasets untouched. To remove a single data item, use cognee.datasets.delete_data(dataset_id, data_id).

​
Examples

​
FAQ

Keep metadata=False (the default) if you want to preserve the relational database. But for a true re-cognify of already-processed data, prune_system() is not enough by itself: it clears graph/vector/cache storage, but it does not reset the per-data-item cognify_pipeline status that incremental cognify() uses to decide what to skip.For the safe rebuild flow, use forget(..., memory_only=True) on the dataset you want to re-process. That preserves raw files, datasets, and data records while clearing graph/vector memory and resetting cognify status:
Setting metadata=True would delete the datasets, data records, and pipeline state from the relational database (PostgreSQL or SQLite), forcing you to add() your data again before re-cognifying.
If you switch VECTOR_DB_PROVIDER, the new vector store starts empty, so you do need to rebuild memory for the datasets you want to query. The safest documented flow is dataset-scoped: update VECTOR_DB_PROVIDER (see Vector Stores), then clear only the dataset’s derived memory and re-cognify it:
This preserves the dataset’s files and relational metadata while rebuilding the graph and embeddings against the new vector store.If you use prune_system(vector=True, metadata=False), remember that it clears the vector storage globally but does not reset cognify status for existing data items, so a plain follow-up cognify() may skip them.
It removes the cache directory (CACHE_ROOT_DIRECTORY, holding cached files such as downloaded ontologies and tutorial data) and, when session caching or usage logging is enabled, prunes the session cache backend (conversation history and usage logs). It never deletes graph, vector, or relational data, so clearing the cache is safe to combine with any re-cognify workflow.