# How Multi-Project Configuration Works in Code-Graph-RAG to Share a Single Graph

> Learn how Code-Graph-RAG efficiently shares a single graph across multiple projects using project name prefixes for isolated subgraphs without database duplication. Optimize your multi-project setup.

- Repository: [Vitali Avagyan/code-graph-rag](https://github.com/vitali87/code-graph-rag)
- Tags: internals
- Published: 2026-08-16

---

**Code-Graph-RAG uses a single Memgraph instance for multiple projects by prefixing all node IDs and edge labels with a project name, creating isolated sub-graphs without database duplication.**

The `vitali87/code-graph-rag` repository implements multi-tenancy through lightweight namespace isolation rather than separate database instances. This design lets teams index dozens of repositories into one shared knowledge graph while maintaining strict logical separation between projects.

## The Project Name as Namespace Prefix

Every indexed repository receives a **project name** that acts as a root namespace. The system derives this automatically from the folder name, or you can override it with `--project-name`.

In [`realtime_updater.py`](https://github.com/vitali87/code-graph-rag/blob/main/realtime_updater.py), the project name becomes the foundation of all graph operations:

```python

# realtime_updater.py lines 258-265

self.updater.project_name          # stores the active project name

f"{self.updater.project_name}."    # prefix for all node/edge identifiers

```

This prefixing happens transparently. When you index Python files from `my-service`, the resulting Cypher queries generate nodes like `my-service.ClassName` rather than bare identifiers. The same Memgraph instance can safely hold `api-gateway.ClassName` and `billing-service.ClassName` without collision.

## Adding Projects to the Shared Graph

The CLI command `cgr start` handles incremental ingestion. Each invocation with `--update-graph` adds another project slice without disturbing existing data.

```bash

# First project: defaults to folder name "legacy-monolith"

cgr start --repo-path ./legacy-monolith --update-graph

# Second project: explicit name for clarity

cgr start --repo-path ./new-api --project-name public-api --update-graph

# Third project: microservice with inferred name "notification-worker"

cgr start --repo-path ./workers/notifications --update-graph

```

All three projects coexist in Memgraph. Queries can target specific projects or span the entire graph.

## Configuration Through AppConfig

No per-project configuration files exist. The [`codebase_rag/config.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/config.py) module defines **AppConfig**, which holds global connection parameters:

```python

# codebase_rag/config.py

MEMGRAPH_HOST = "localhost"
MEMGRAPH_PORT = 7687

# ... other shared settings

```

Every project connects to the same Memgraph host and port. Isolation happens at the data layer through prefixed identifiers, not at the connection layer through separate databases.

## Querying Projects: Scoped and Cross-Project Access

The Python SDK exposes project-scoped loading through `GraphLoader`:

```python
from codebase_rag.graph_loader import GraphLoader

# Load only the notification-worker sub-graph

loader = GraphLoader(project="notification-worker")
graph = loader.load()

# Load another project for comparison

legacy = GraphLoader(project="legacy-monolith").load()

```

For ad-hoc exploration, the CLI accepts raw Cypher:

```bash

# List all indexed projects

cgr query "MATCH (p:Project) RETURN p.name"

# Find similar classes across projects

cgr query "MATCH (c:Class) WHERE c.name CONTAINS 'Handler' RETURN c.project, c.name"

```

## The --clean Flag: Global Reset Behavior

The `--clean` flag requires caution. According to the source in [`README.md`](https://github.com/vitali87/code-graph-rag/blob/main/README.md) (lines 136-141), this operation **deletes all projects** in the shared graph—not merely the current one.

```bash

# WARNING: removes every indexed project

cgr start --clean

# Safer: re-index a single project (overwrites only its namespace)

cgr start --repo-path ./updated-api --project-name public-api --update-graph

```

The CLI emits a warning before executing `--clean` because the operation truncates the entire Memgraph database.

## Implementation Architecture

| Component | Responsibility | Key Source Location |
|-----------|--------------|---------------------|
| [`realtime_updater.py`](https://github.com/vitali87/code-graph-rag/blob/main/realtime_updater.py) | Project-scoped key generation | Lines 258-265 |
| [`README.md`](https://github.com/vitali87/code-graph-rag/blob/main/README.md) | User-facing multi-project documentation | Lines 136-141 |
| [`codebase_rag/config.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/config.py) | Global Memgraph connection settings | `AppConfig` class |
| [`codebase_rag/graph_loader.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/graph_loader.py) | Project-filtered graph loading | `GraphLoader(project=...)` |

## Summary

- **Single Memgraph instance** hosts multiple projects through identifier prefixing.
- **Project name** (`--project-name` or folder-derived) isolates all nodes and edges.
- **[`realtime_updater.py`](https://github.com/vitali87/code-graph-rag/blob/main/realtime_updater.py)** implements the prefix injection in generated Cypher.
- **`GraphLoader`** enables single-project views for SDK consumers.
- **`--clean` resets everything**—use it sparingly across multi-project deployments.

## Frequently Asked Questions

### What happens if two projects have the same folder name?

Code-Graph-RAG uses the folder name as the default project identifier. If you index `/home/user/api` and `/opt/api` separately, both default to `api`, causing collision. Always use `--project-name` to disambiguate: `--project-name user-api` versus `--project-name opt-api`.

### Can I query relationships across projects in Cypher?

Yes. The project prefix lives inside node IDs and labels, but Cypher `MATCH` clauses can traverse any edge. To restrict scope, filter by the project property: `WHERE node.id STARTS WITH "project-name."` or use `GraphLoader` for automatic filtering.

### Does each project need its own running Memgraph process?

No. One Memgraph process serves all projects. Connection parameters in [`codebase_rag/config.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/config.py) apply globally. The multi-tenancy is logical, not operational—reducing infrastructure overhead.

### How do I migrate a project to a fresh Memgraph instance?

Export the project-specific nodes and edges using `cgr query` with project filters, then import into the new instance. There is no built-in `export --project` command; use Cypher `MATCH ... WHERE ...` predicates to extract subsets.