# How code-review-graph Compares to LSP-Based Tools Like Pyright or TypeScript

> Compare code-review-graph's persistent SQLite graph with LSP tools like Pyright and TypeScript for cross-language and single-language code analysis. Understand their distinct strengths.

- Repository: [Tirth Kanani/code-review-graph](https://github.com/tirth8205/code-review-graph)
- Tags: comparison
- Published: 2026-07-18

---

**code-review-graph builds a persistent, cross-language SQLite graph for multi-hop structural queries, while LSP-based tools like pyright and the TypeScript language server provide compiler-precise, in-memory symbol resolution optimized for single-language editing.**

The open-source `code-review-graph` (CRG) repository creates a durable structural index of your codebase, fundamentally differing from Language Server Protocol (LSP) implementations in both architecture and intended workflow. While tools like pyright and tsserver focus on real-time editing assistance with exact type information, CRG optimizes for AI-assisted code review, impact analysis, and cross-language navigation through a persistent graph database. Understanding how code-review-graph compares to LSP-based tools helps teams choose the right approach for automated reviews versus interactive development.

## Core Architectural Differences

### Parsing Engines and Representation

LSP-based tools rely on compiler front-ends or language-specific type checkers—in pyright's case, a dedicated Python type-checker; for TypeScript, the tsserver leverages the official compiler API. These engines maintain sophisticated semantic understanding but operate strictly within their language boundary.

In contrast, `code-review-graph` uses **Tree-sitter** to parse source files into an abstract syntax tree (AST) across approximately 35 languages and notebook formats. As implemented in [`code_review_graph/parser.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/parser.py), the parser extracts nodes representing functions, classes, imports, and tests, then persists edges (calls, inheritance, test coverage) into a **SQLite graph store** ([`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py)). This creates a language-agnostic structure where cross-language references are first-class citizens rather than unsupported boundaries.

### Persistence Models

The persistence strategy marks a fundamental divergence between these approaches. LSP servers maintain **in-memory indexes** that exist only for the duration of the editor session; when the process restarts, all analysis must be rebuilt from scratch.

CRG persists its graph on disk at `.code-review-graph/graph.db`, surviving editor restarts, CI runs, and multiple client connections. According to the repository's FAQ documentation ([`docs/FAQ.md`](https://github.com/tirth8205/code-review-graph/blob/main/docs/FAQ.md)), this persistent storage enables the tool to answer complex historical queries without re-parsing entire repositories on every request.

### Update Strategies

LSP tools typically re-parse files on each request or editor save event, which can become expensive in large monorepos. The TypeScript server and pyright both rebuild their internal state frequently to ensure diagnostic accuracy.

CRG implements **incremental updates**: only changed files trigger re-parsing (approximately 2 seconds for roughly 3,000 files). This optimization makes the tool suitable for continuous integration pipelines where full rebuilds would waste compute resources.

## Query Capabilities and Performance

### Single-Symbol vs. Multi-Hop Analysis

LSP excels at precise, compiler-level results for individual symbols—go-to-definition, find-references, diagnostics, and safe rename operations. These queries return exact locations because they leverage full semantic analysis.

CRG specializes in **multi-hop structural queries** that trace relationships across multiple files. Through MCP tools registered in [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py)—such as `query_graph_tool`, `get_impact_radius_tool`, and `detect_changes_tool`—the system can identify callers-of-callers, execution flow paths, test coverage gaps, and blast-radius analysis for proposed changes. As noted in [`docs/FAQ.md`](https://github.com/tirth8205/code-review-graph/blob/main/docs/FAQ.md), CRG's call resolution operates at the AST level using heuristics, meaning edges may be marked as **EXTRACTED**, **INFERRED**, or **AMBIGUOUS** rather than compiler-guaranteed.

### Token Efficiency for AI Reviews

When integrated with AI systems, CRG demonstrates significant efficiency gains over LSP-based approaches. LSP requires agents to repeatedly issue individual calls and re-read multiple files, making it token-inefficient for multi-file review tasks.

CRG returns **compact, token-efficient context**—approximately 100 tokens for ultra-compact queries—containing only relevant nodes and edges. The README benchmarks show a median **82× token reduction** per question compared to traditional approaches, making it specifically designed for AI-assisted workflows.

## Language Support and Extensibility

### Cross-Language Edge Handling

LSP servers operate in isolation; pyright knows nothing about your TypeScript files, and tsserver cannot see your Python imports. Each daemon maintains its own state without cross-language awareness.

CRG treats **cross-language edges as first-class entities**. For example, a Python file importing a JavaScript module creates a direct edge in the graph queryable through the same interface as intra-language calls. This enables analysis of polyglot systems where boundaries between languages blur, such as Node.js applications with Python data processing scripts.

### Adding New Languages

Extending LSP functionality requires language-specific plugins or custom protocol extensions, demanding significant development effort for each new language.

CRG simplifies this through declarative configuration. New languages can be supported by dropping a [`languages.toml`](https://github.com/tirth8205/code-review-graph/blob/main/languages.toml) file into the configuration without modifying core source code ([`code_review_graph/parser.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/parser.py) handles the Tree-sitter grammar integration dynamically).

## Practical Usage Examples

### Building and Querying the Graph

Initialize or incrementally update the structural index:

```bash
code-review-graph build

```

For a 500-file repository, this completes in approximately 10 seconds.

### Querying Multi-Hop Callers

Query callers across languages using Python against the MCP server:

```python
import json
import urllib.request

def query_callers(name):
    payload = {
        "jsonrpc": "2.0",
        "method": "query_graph_tool",
        "params": {"pattern": "callers_of", "target": name},
        "id": 1,
    }
    data = json.dumps(payload).encode()
    resp = urllib.request.urlopen("http://127.0.0.1:5555", data=data)
    return json.load(resp)

print(query_callers("handleRequest"))

```

Unlike pyright or tsserver, this returns both TypeScript and any cross-language callers (such as Python scripts invoking compiled JavaScript modules) in a single request.

### Impact Analysis and Blast Radius

Detect changes and assess risk efficiently:

```bash
code-review-graph detect-changes --brief

```

This produces a JSON payload containing affected `functions`, `tests`, and `risk` scores, while displaying token savings metrics. Achieving equivalent results with pyright would require chaining multiple `--verifytypes` calls with custom scripting to traverse the call graph manually.

## When to Use Each Tool

Choose **LSP-based tools** when you need compiler-precise editing features: safe refactoring, exact type diagnostics, or guaranteed-accurate symbol renaming within a single language. Pyright and the TypeScript language server provide the semantic accuracy necessary for writing and editing code safely.

Select **code-review-graph** when your workflow requires cross-file, multi-hop insights: AI-assisted code reviews, architectural impact analysis, risk scoring across repository boundaries, or understanding blast radius of changes. The persistent SQLite graph and MCP tool interface optimize for these review-centric scenarios where token efficiency and cross-language visibility matter more than compiler-level type precision.

## Summary

- **code-review-graph** persists a cross-language SQLite graph (`graph.db`) supporting ~35 languages, while LSP tools maintain temporary, language-specific in-memory indexes.
- CRG provides **multi-hop structural queries** (callers-of-callers, blast-radius analysis) via MCP tools like `query_graph_tool` and `get_impact_radius_tool`, whereas LSP excels at single-symbol resolution.
- Updates are **incremental** in CRG (~2 seconds for 3,000 files), compared to on-demand re-parsing in LSP servers.
- CRG achieves approximately **82× token reduction** for AI contexts by returning compact subgraphs rather than full file contents.
- **Cross-language edges** are first-class in CRG (e.g., Python importing JavaScript), while LSP servers remain isolated by language.
- New languages integrate via [`languages.toml`](https://github.com/tirth8205/code-review-graph/blob/main/languages.toml) configuration in CRG, versus requiring language-specific LSP extensions.

## Frequently Asked Questions

### Is code-review-graph a replacement for pyright or TypeScript language server?

No. code-review-graph complements rather than replaces LSP-based tools. Use pyright or tsserver for daily editing, diagnostics, and refactoring where compiler-precise type information is essential. Use CRG for automated code reviews, impact analysis, and AI-assisted workflows that benefit from persistent cross-language graph queries.

### How accurate are the call relationships in code-review-graph compared to LSP?

CRG's call resolution is **AST-level and heuristic**. According to [`docs/FAQ.md`](https://github.com/tirth8205/code-review-graph/blob/main/docs/FAQ.md), edges can be **EXTRACTED**, **INFERRED**, or **AMBIGUOUS**. LSP tools provide compiler-guaranteed accuracy because they use full type checkers. CRG trades absolute precision for speed, persistence, and cross-language coverage.

### Can I use code-review-graph with my existing LSP setup?

Yes. CRG operates independently through its MCP server interface (exposed in [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py)). You can run `code-review-graph build` alongside your existing LSP configuration without conflicts, since CRG writes to its own SQLite database (`.code-review-graph/graph.db`) rather than interfering with editor-specific caches.

### Does code-review-graph support TypeScript and Python equally?

Yes. Both TypeScript and Python are supported via Tree-sitter parsers. CRG handles `.ts`, `.tsx`, and `.py` files within the same graph, enabling queries that trace execution flow across TypeScript frontend code and Python backend services—something impossible with isolated LSP servers.