> ## 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.

# Data Isolation and Multi-Tenancy

> How Cognee isolates memory between users, teams and tenants: per-dataset storage, dataset-level permissions, and tenants and roles for enterprise access control

## How Cognee isolates memory

With multi-user mode on (the default since 0.5.0 when your storage supports it), Cognee keeps each user's and each team's memory separate on a single instance. The isolation boundary is the **dataset**: each dataset has its own graph and vector store (see [the table below](#where-isolation-happens-datasets-vs-databases)), and every read or write is checked against dataset-level permissions. Those permissions are granted to three kinds of principals:

* **Users** own datasets and can be given read, write, share or delete permission on other users' datasets.
* **Roles** group users inside a tenant, for example one team, and can be granted permissions as a group.
* **Tenants** represent an organization; a permission granted to a tenant applies to all of its members.

## What multi-user mode is

Multi-user mode is the architectural directive in Cognee that enforces strict data isolation between different users and [datasets](/core-concepts/further-concepts/datasets). It is primarily controlled by the environment variable `ENABLE_BACKEND_ACCESS_CONTROL`.

Starting with version 0.5.0, this mode is enabled by default when your configured storage setup supports it. This keeps Cognee secure by default without forcing unsupported database combinations into multi-user mode.

## Upgrading to v0.5.0 or Later

<Warning>
  If you are upgrading from a version earlier than `0.5.0`, data ingested before the upgrade may be inaccessible in multi-user mode because it was not associated with a specific user. To restore access to pre-upgrade data, start Cognee with `ENABLE_BACKEND_ACCESS_CONTROL=false`, then migrate or re-ingest that data before re-enabling multi-user mode.
</Warning>

For configuration requirements and supported handler/provider combinations, see [Permissions Setup](/setup-configuration/permissions) and [Dataset Database Handlers](/core-concepts/multi-user-mode/dataset-database-handlers/dataset-database-handlers-what-are-they).

## When multi-user mode is active

When multi-user mode is active, the system unlocks several multi-tenant features:

* **Isolated Recall**: Retrieval operations are strictly scoped to datasets the authenticated user has explicit read access to. To learn more about the permissions system and access types, read about our [Permission System](/core-concepts/multi-user-mode/permissions-system/overview).

* **Granular Management**: Remembering or forgetting documents is scoped at the dataset level, preventing global knowledge pool pollution.

* **Automatic Routing**: The system automatically determines which local/cloud database or logical schema to connect to based on the dataset. This is done with the help of [Dataset Database Handlers](/core-concepts/multi-user-mode/dataset-database-handlers/dataset-database-handlers-what-are-they).

## Where isolation happens: datasets vs. databases

Dataset isolation is handled differently depending on whether backend access control is enabled. This applies to the **graph and vector stores**, not the relational store:

| | Single-user mode (`ENABLE_BACKEND_ACCESS_CONTROL=false`) | Multi-user mode (`ENABLE_BACKEND_ACCESS_CONTROL=true`) |
| - | - | - |
| **Graph / vector store** | One shared instance for all datasets | One backend per dataset, resolved by a [Dataset Database Handler](/core-concepts/multi-user-mode/dataset-database-handlers/dataset-database-handlers-what-are-they) |
| **Separation between datasets** | None at query time — all datasets share one store and `datasets`/`dataset_ids` filters are ignored | Physical — each dataset's data lives in its own database |
| **Access control** | Off (no auth) | Enforced per [dataset](/core-concepts/multi-user-mode/permissions-system/datasets) via read/write/share/delete permissions |
| **Tenant scope** | N/A | A [tenant](/core-concepts/multi-user-mode/permissions-system/tenants) is a group of users that shares dataset permissions — it is not itself a separate database |

So a "workspace" or "tenant" is not a database boundary. The database boundary in multi-user mode is the **dataset**: each dataset is routed to its own physical graph/vector store, while tenants and users simply control *who can reach which datasets*.

<Columns cols={2}>
  <Card title="Permission System" icon="user" href="/core-concepts/multi-user-mode/permissions-system/overview">
    Learn about the permission system that powers multi-user mode
  </Card>

  <Card title="Dataset Database Handlers" icon="building" href="/core-concepts/multi-user-mode/dataset-database-handlers/dataset-database-handlers-what-are-they">
    Understand database connection resolution per dataset
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.