Scalability Benchmarks

Copy MarkdownOpen

GitHub vs Coregit — Head-to-Head

Real-world benchmarks comparing GitHub REST API and Coregit API for identical operations. All tests run from the same machine, same network, same time window.

Test conditions: Kazakhstan → CF edge / US-East, private repos with authentication, April 2026. 10 iterations + 2 warmup per operation, median (p50) reported.

Write Operations

Coregit's atomic multi-file commit is the key differentiator. GitHub requires N+3 sequential API calls (N blobs + get HEAD + create tree + create commit + update ref). Coregit does it in 1 call.

Coregit's advantage grows with file count because GitHub's per-blob API calls accumulate linearly:

• 1 file: GitHub faster (Contents API shortcut, less server-side work)
• 5 files: Coregit 1.9x faster
• 10 files: Coregit 2.0x faster
• 100 files: Coregit 3.6x faster
• 1,000 files (projected): ~10x+ faster

Read Operations

Coregit uses edge-cached flat tree maps and commit lists. First request populates the cache; all subsequent requests hit cache. Tree listing is 2.4x faster because Coregit resolves it in 1 call — GitHub needs 3 (ref → commit → tree).

Other Operations

GitHub's single-op write operations are faster due to monolith architecture with in-memory caches (0 network hops between components). Coregit is a distributed system on serverless edge compute where each component (edge cache, object storage, coordination layer, connection pooler) is a separate network call.

Architecture

Coregit's performance stack:

• Serverless edge compute — serverless compute at edge or near backend (Smart Placement)
• Object storage — git object storage (content-addressed, immutable)
• Edge cache — caching layer (tree maps, auth, repo metadata, commit lists, embeddings)
• Coordination layer — rate limiting, session state, per-repo hot layer
• Connection pooler — PostgreSQL connection pooling and query caching

Caching layers

Session API (Zero-Wait Protocol)

For AI agents doing many operations in sequence, the Session API eliminates per-request auth overhead:

1. POST /v1/session — auth once, get session ID
2. All requests with X-Session-Id header — auth validated via coordination layer (~1ms)
3. DELETE /v1/session/:id — close session, flush pending writes

Methodology

All benchmarks use the same pattern:

# Timing with millisecond precision
ms() { python3 -c "import time; print(int(time.time()*1000))"; }
t1=$(ms); <operation>; t2=$(ms); echo "$((t2-t1)) ms"

All benchmarks use gh api for GitHub and cgt CLI for Coregit. Create repo uses gh repo create. All authenticate with API keys (private repos). 3 runs per operation, median reported.

For multi-file commits on GitHub, each blob is created with a separate POST /repos/:owner/:repo/git/blobs call, followed by tree creation, commit creation, and ref update — matching the minimum required API calls.

Reproduce

# GitHub: commit 10 files (13 API calls)
for i in $(seq 1 10); do
  gh api repos/OWNER/REPO/git/blobs -f content="file $i" -f encoding=utf-8
done
# + get HEAD + create tree + create commit + update ref

# Coregit: commit 10 files (1 API call)
cgt commit my-repo -b main -m "add 10 files" \
  -f f1.ts:='1' -f f2.ts:='2' ... -f f10.ts:='10'