Skip to main content
Henrik Albihn
Henrik Albihn
Creator of ticket-rs

A Bold Claim

I might have built the fastest ticketing system on Earth. This isn’t marketing hyperbole. It’s physics.

The Speed of Light Problem

JIRA, Linear, Trello, Asana, and every other cloud-based ticketing system share a constraint: the speed of light. When you click “create issue” in JIRA, here’s what happens:
  1. Your browser sends a request to Atlassian’s servers
  2. The request travels through multiple network hops
  3. A load balancer routes it to an application server
  4. The app server queries a database
  5. The database returns results
  6. The app server processes the response
  7. The response travels back through the internet
  8. Your browser renders the result
Best case scenario? 100-300ms if you’re on a good connection and the servers are nearby. Realistic scenario? 500ms-2s depending on load, network conditions, and how many microservices are involved.
The speed of light in fiber optic cable is about 200,000 km/s. A round trip from San Francisco to an AWS data center in Virginia (~4,000 km) takes a minimum of 40ms just for the physics. Add TCP handshakes, TLS negotiation, and server processing… you get the idea.

The Local-First Advantage

ticket-rs doesn’t have this problem. When you run tk list:
  1. Read files from disk (~0.1ms)
  2. Parse YAML frontmatter (~2ms)
  3. Format output (~0.5ms)
  4. Done
Total time: 7-8ms No network. No database server. No load balancers. No microservices. Just your SSD and a single Rust binary.

Cloud Ticketing

~500ms-2s per operationLimited by network latency, server load, and database queries

ticket-rs

~7-21ms per operationLimited only by disk I/O and CPU speed
That’s not a 2x improvement. That’s 25-100x faster.

But Wait, I Have Benchmarks

Now, I can’t easily benchmark JIRA (their servers, their rules). But I can benchmark against the local tools that inspired ticket-rs:
  • ticket — A bash implementation
  • beads — Steve Yegge’s Go implementation with SQLite daemon
  • kardianos-ticket — A Go implementation with trie-based YAML parsing
  • vibe-ticket — A Rust implementation
These are the closest “apples to apples” comparisons I have—all local-first, all CLI-based, all designed for AI-native workflows.

The Results

ImplementationMedian TimeSpeedup
ticket-rs (Rust CLI (tk))9.0ms6.2x faster
kardianos/ticket (Go trie YAML)9.7ms5.8x faster
nwiizo/vibe-ticket (Rust (archived))16.2ms3.5x faster
ticket-py (Python bindings via PyO3)24.3ms2.3x faster
wedow/ticket (Bash)35.1ms1.6x faster
steveyegge/beads (Go daemon)55.9ms1.0x faster
steveyegge/beads (Go direct)58.8ms1.1x slower
Benchmarks run with 500 tickets, 30 iterations. Data source: benchmark-data.json
vibe-ticket was archived in January 2026 and only benchmarks read-only commands (list, ready, stats). ticket-rs includes the full command suite with write operations.
The beads daemon mode is actually slower than bash because of the overhead of communicating with a background SQLite process. Zero daemons turns out to be a performance advantage, not just a philosophy.

Scaling Analysis

We tested with datasets from 10 to 1,000 tickets: ticket-rs: O(n) scaling with excellent constants bash: O(n²) for operations requiring full repository scans beads daemon: Constant daemon overhead + O(n) parsing At 1,000 tickets, the performance gap widens further. At 10,000 tickets, bash becomes unusable while ticket-rs stays snappy.

The “Fastest on Earth” Claim

Okay, let’s be precise about what I’m claiming: For the specific use case of:
  • Local-first issue tracking
  • CLI-based operations
  • AI agent workflows
  • Dependency-aware prioritization
ticket-rs is likely the fastest option available. Is it faster than a post-it note? No. Is it faster than shouting across the office? Definitely not. But for a real ticketing system with features like:
  • Dependency graphs
  • PageRank-based prioritization
  • BM25 search
  • Bidirectional sync with Linear/GitHub
  • AI-native command output
…I haven’t found anything faster.
If you know of a faster ticketing system, please open an issue. I genuinely want to know. I’ll update the benchmarks.

Why This Matters

Speed matters for developer experience, but it matters even more for coding agents. When Claude Code or Cursor runs tk triage in an agentic loop, every millisecond of latency slows the entire cycle. A 500ms API call means the agent sits idle. Across dozens of tool calls per session, that latency compounds. At 14-21ms per operation, ticket-rs lets coding agents:
  • Query project state on every iteration without bottlenecking
  • Run tk prime at session start for instant context engineering
  • Iterate on dependency graphs in real time
  • Stay responsive at 1,000+ tickets
The same speed benefits apply to CI/CD pipelines, pre-commit hooks, and shell scripts. Fast tools make everything downstream faster. Fast tools make fast agents.

Try It Yourself

# Install ticket-rs
curl -fsSL https://ticket-rs.io/install.sh | sh

# Initialize a ticket database
tk init

# Create some issues
tk create "Build the thing" -t feature -p 1
tk create "Test the thing" -t task -p 2

# Add a dependency
tk dep add tk-2 tk-1

# See what's ready to work on
tk ready

# Get AI-powered recommendations
tk triage
Run tk triage and watch it complete before you can blink.

The Benchmark Suite

Want to reproduce these results? We maintain a benchmark suite:
cd pypi/benchmarks
uv sync
ticket-bench all
This runs:
  • Repeated benchmarks (30 iterations, 500 tickets)
  • Scaling analysis (10, 50, 100, 500, 1,000 tickets)
  • Statistical analysis with confidence intervals
Full methodology and raw data: pypi/benchmarks/BENCHMARK_REPORT.md Benchmark data (JSON): web/src/data/benchmark-data.json

Conclusion

Is ticket-rs the fastest ticketing system on Earth? Technically, I can only prove it’s faster than bash scripts, Go implementations, and (by inference) any cloud-based system limited by network physics. But until someone shows me a faster dependency-aware, AI-native, graph-analytics-enabled ticketing system… I’m claiming the title. The fastest ticketing system is the one that runs on your machine.