📊RabbitStream vs Jito Shredstream: Benchmarks
RabbitStream transaction delivery benchmarked head-to-head against Jito ShredStream across multiple regions.
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.
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
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
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
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
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
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
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
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.
Last updated