> For the complete documentation index, see [llms.txt](https://docs.shyft.to/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.shyft.to/solana-shredstreaming/rabbitstream-vs-jito-shredstream-benchmarks.md).
# RabbitStream vs Jito Shredstream: Benchmarks
RabbitStream delivers Solana transaction data at the shred layer — the earliest point at which transaction data exists on the network. Unlike Yellowstone gRPC, which streams you data after the RPC has processed it, RabbitStream ingests raw UDP shreds directly from multiple Shred sources simultaneously. This architecture eliminates relay dependencies and RPC queue overhead, placing the data in your client's hands before any execution, log, or balance change has been recorded.
{% hint style="info" %}
A Shred is a \~1,228-byte UDP packet produced by the validator before block finalization.
{% endhint %}
This section breaks down a head-to-head performance comparison between RabbitStream and Jito ShredStream, measured across three production regions.
### Benchmark: RabbitStream vs. Jito ShredStream
#### **Methodology**
Benchmarks were conducted on live mainnet traffic across three regions, with both endpoints running side-by-side on every run.
* **Tool:** [geyserbench v1.2.2](https://github.com/solstackapp/geyserbench)
* **Sample size:** 10,000–10,011 valid transactions per run
* **Runs:** 2 per region (6 total)
* **Regions tested:** Frankfurt (FRA), New York (NY), Amsterdam (AMS)
* **Method:** Both endpoints connected simultaneously to the same live transaction stream. Every delivery tagged by which arrived first.
* **Test node:** Dedicated bare-metal server (AMD EPYC 9254, 384 GB RAM), co-located in the respective test region with under 1ms ping to both endpoints. Client-side network variance was not a factor in the results.
#### **Results Summary**
| Region | RabbitStream Win Rate | Jito Win Rate | Jito P50 Behind | Jito P99 Behind |
| --------------- | ------------------------------------------- | ------------- | --------------- | --------------- |
| Frankfurt (FRA) | 97.77% | 2.23% | 6.72ms | 46.86ms |
| New York (NY) | 97.19% | 2.81% | 5.29ms | 81.50ms |
| Amsterdam (AMS) | 92.67% | 7.33% | 3.79ms | 15.45ms |
*Figures shown are from Run 1 in each region. Full per-run data below.*
RabbitStream arrived first in both regions tested. Both feeds achieved 100% delivery of valid transactions with zero backfill — the difference is not reliability, it is who gets there first.
***
**Frankfurt (FRA) — Full Results**
RabbitStream vs Jito Shredstream: Benchmarks (Frankfurt)
| Run | RabbitStream Win Rate | Jito P50 Behind | Jito P99 Behind |
| ----- | ---------------------------- | --------------- | --------------- |
| Run 1 | 97.77% (9,780 / 10,003 txns) | 6.72ms | 46.86ms |
| Run 2 | 97.31% | 4.19ms | 25.74ms |
Frankfurt results were consistent across both runs. The win rate gap did not meaningfully change between iterations. Jito ShredStream's P99 ranged from 25.74ms to 46.86ms.
***
**New York (NY) — Full Results**
RabbitStream vs Jito Shredstream: Benchmarks (New York)
| Run | RabbitStream Win Rate | Jito P50 Behind | Jito P99 Behind |
| ----- | ---------------------------- | --------------- | --------------- |
| Run 1 | 97.19% (9,723 / 10,004 txns) | 5.29ms | 81.50ms |
| Run 2 | 96.52% | 3.87ms | 82.06ms |
New York is where Jito's infrastructure is most concentrated. Despite this, RabbitStream arrived first in over 96.5% of transactions across both runs. Jito ShredStream's P99 held near 82ms in both iterations, confirming this is a structural pattern, not an outlier.
***
**Amsterdam (AMS) — Full Results**
RabbitStream vs Jito Shredstream: Benchmarks (Amsterdam)
| Run | RabbitStream Win Rate | Jito P50 Behind | Jito P95 Behind | Jito P99 Behind |
| ----- | ---------------------------- | --------------- | --------------- | --------------- |
| Run 1 | 92.67% (9,268 / 10,001 txns) | 3.79ms | 11.57ms | 15.45ms |
| Run 2 | 98.62% (9,873 / 10,011 txns) | 5.04ms | 13.21ms | 16.73ms |
Amsterdam showed the widest variance in win rate across runs — 92.67% in Run 1 and 98.62% in Run 2. Despite this, RabbitStream arrived first in the majority of transactions in both runs, and Jito's P99 remained capped below 17ms across both iterations. Both feeds delivered zero backfill across 10,000+ transactions per run.
### **Across All Runs**
| Region | Run | RabbitStream Win Rate | Jito P50 Behind | Jito P99 Behind |
| --------- | ----- | --------------------- | --------------- | --------------- |
| Frankfurt | Run 1 | 97.77% | 6.72ms | 46.86ms |
| Frankfurt | Run 2 | 97.31% | 4.19ms | 25.74ms |
| New York | Run 1 | 97.19% | 5.29ms | 81.50ms |
| New York | Run 2 | 96.52% | 3.87ms | 82.06ms |
| Amsterdam | Run 1 | 92.67% | 3.79ms | 15.45ms |
| Amsterdam | Run 2 | 98.62% | 5.04ms | 16.73ms |
***
{% hint style="warning" %}
See how Shyft RPC performs against Yellowstone gRPC in our [RabbitStream vs Yellowstone gRPC](https://docs.shyft.to/solana-shredstreaming/pages/wV8xcVXrbVHyCIznl13D#rabbitstream-vs.-yellowstone-grpc-benchmarks) benchmark.
{% endhint %}
### Why RabbitStream Arrives First
RabbitStream ingests raw UDP shreds from multiple sources simultaneously, taking whichever propagation path delivers first. There is no single relay to route through and no RPC queue to wait behind. The only server-side work before delivery is shred decoding, which adds negligible overhead.
Jito ShredStream routes shreds through Jito's Block Engine network. This gives it direct relationships with certain Solana leaders — which explains why Jito wins a small share of deliveries in each region — but introduces a single relay dependency for all other shreds. Across all four runs and both regions, Jito's share never exceeded 3% and its P99 never dropped below 25ms.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.shyft.to/solana-shredstreaming/rabbitstream-vs-jito-shredstream-benchmarks.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.