> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ticket-rs.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The Fastest Ticketing System on Earth (Probably)

> How local-first architecture makes ticket-rs orders of magnitude faster than cloud-based alternatives

<Frame>
  <div style={{ display: 'flex', alignItems: 'center', gap: '16px', padding: '16px' }}>
    <img src="https://avatars.githubusercontent.com/u/61203850?v=4" alt="Henrik Albihn" style={{ width: '64px', height: '64px', borderRadius: '50%' }} />

    <div>
      <div style={{ fontWeight: 600, fontSize: '16px' }}>Henrik Albihn</div>
      <div style={{ color: '#666', fontSize: '14px' }}>Creator of ticket-rs</div>

      <div style={{ display: 'flex', gap: '12px', marginTop: '8px' }}>
        <a href="https://github.com/henrikalbihn" style={{ color: '#666' }}>GitHub</a>
        <a href="https://bsky.app/profile/henrik.sh" style={{ color: '#666' }}>Bsky</a>
      </div>
    </div>
  </div>
</Frame>

## 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.

<Info>
  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.
</Info>

***

## 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.

<CardGroup cols={2}>
  <Card title="Cloud Ticketing" icon="cloud">
    \~500ms-2s per operation

    Limited by network latency, server load, and database queries
  </Card>

  <Card title="ticket-rs" icon="bolt">
    \~3–20ms per operation

    Limited only by disk I/O and CPU speed
  </Card>
</CardGroup>

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**](https://github.com/wedow/ticket) — A bash implementation
* [**beads**](https://github.com/steveyegge/beads) — Steve Yegge's Go implementation with SQLite daemon
* [**kardianos-ticket**](https://github.com/kardianos/ticket) — A Go implementation with trie-based YAML parsing
* [**vibe-ticket**](https://github.com/nwiizo/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

{/* Generated: 2026-02-12T06:29:39.402263+00:00*/}

| Implementation                           | Median Time | Speedup     |
| ---------------------------------------- | ----------- | ----------- |
| **ticket-rs** (Rust CLI (tk))            | **9.0ms**   | 6.2x faster |
| kardianos/ticket (Go trie YAML)          | 9.7ms       | 5.8x faster |
| nwiizo/vibe-ticket (Rust (archived))     | 16.2ms      | 3.5x faster |
| **ticket-py** (Python bindings via PyO3) | **24.3ms**  | 2.3x faster |
| wedow/ticket (Bash)                      | 35.1ms      | 1.6x faster |
| steveyegge/beads (Go daemon)             | 55.9ms      | 1.0x faster |
| steveyegge/beads (Go direct)             | 58.8ms      | 1.1x slower |

<Info>
  Benchmarks run with 500 tickets, 30 iterations.
  Data source: [benchmark-data.json](https://github.com/ticket-rs/ticket/blob/main/web/src/data/benchmark-data.json)
</Info>

<Warning>
  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.
</Warning>

<Warning>
  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.
</Warning>

***

## 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.

<Info>
  If you know of a faster ticketing system, please [open an
  issue](https://github.com/ticket-rs/ticket/issues). I genuinely want to know.
  I'll update the benchmarks.
</Info>

***

## 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

```bash theme={null}
# 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:

```bash theme={null}
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`](https://github.com/ticket-rs/ticket/blob/main/pypi/benchmarks/BENCHMARK_REPORT.md)

Benchmark data (JSON): [`web/src/data/benchmark-data.json`](https://github.com/ticket-rs/ticket/blob/main/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.**

<CardGroup cols={2}>
  <Card title="Get Started" icon="rocket" href="/quickstart">
    Install ticket-rs in 60 seconds
  </Card>

  <Card title="Benchmarks" icon="chart-bar" href="https://github.com/ticket-rs/ticket/blob/main/pypi/benchmarks/BENCHMARK_REPORT.md">
    View full benchmark report
  </Card>
</CardGroup>