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 ticket files from disk (sub-millisecond)
  2. Parse YAML frontmatter (a few ms for ~500 tickets)
  3. Format output (sub-millisecond)
  4. Done
Total time: under 10ms on a small repo, ~10–20ms at 500 tickets. 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

~3–20ms per operationLimited only by disk I/O and CPU speed
That’s not a 2x improvement. That’s 25–500x faster depending on which end of each range you compare.

​
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

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 under 20ms per analytics operation (even at 500-ticket scale), 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

Run tk triage and watch it complete before you can blink.

​
The Benchmark Suite

Want to reproduce these results? We maintain a benchmark suite:
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.

Get Started

Install ticket-rs in 60 seconds

Benchmarks

View full benchmark report