If you are building anything that reacts to Bluesky in real time – a feed generator, a bot, an analytics pipeline, a keyword alerting service – you have two options for getting the data. Picking the wrong one costs you either a lot of CPU or a guarantee you needed.
Here is the practical comparison.
The Short Version
| Firehose | Jetstream | |
|---|---|---|
| Format | CBOR / CAR blocks | JSON |
| Cryptographic verification | Yes – signed commits | No |
| Bandwidth | High | Roughly an order of magnitude lower |
| CPU cost | Significant – CAR decoding | Minimal – parse JSON |
| Server-side filtering | No – you get everything | Yes – by collection and DID |
| Implementation effort | Days | Under an hour |
| Right for | Verification, archival, full protocol handling | Almost everything else |
Default to Jetstream. If you cannot articulate why you need signature verification, you do not need it.
What the Firehose Actually Gives You
The firehose is the AT Protocol's raw event stream. Every repository commit across the network – every post, like, follow, block, profile edit, account event – arrives as a signed, CBOR-encoded message containing CAR blocks.
What you get for that complexity:
- Cryptographic verification. Each commit is signed by the repository's key. You can prove a record genuinely came from the account claiming it, without trusting any intermediary.
- Completeness. Identity events, account status changes, handle changes, tombstones – the full protocol surface, not just record writes.
- Cursor-based replay. Reconnect with a sequence number and get everything you missed, within the relay's retention window.
What it costs you: real bandwidth, real CPU for CAR decoding, and a meaningful amount of implementation work to handle the block structure correctly. Our firehose streaming guide walks through the full implementation.
What Jetstream Gives You
Jetstream is a service that consumes the firehose, does the decoding work once, and re-emits events as plain JSON over a WebSocket.
The practical difference is dramatic. Instead of decoding CAR blocks, you get a JSON object with the record already extracted. Instead of receiving the entire network's traffic and filtering client-side, you can subscribe to specific collections – posts only, or likes only – and specific DIDs, filtered server-side before it hits your connection.
Bandwidth drops by roughly an order of magnitude. CPU drops to near nothing. A Jetstream consumer that does something useful is about forty lines of code.
What you give up: signature verification. Jetstream tells you what it saw; you are trusting Jetstream. For the overwhelming majority of applications, that is a completely acceptable trade – you are already trusting a relay operator somewhere in the chain.
Our Jetstream guide covers the connection details and filtering options.
Decision Table
| You are building | Use | Why |
|---|---|---|
| Feed generator | Jetstream | Filter by collection, no verification needed |
| Keyword alerting | Jetstream | Posts collection only, tiny footprint |
| Trending hashtags | Jetstream | High volume, simple aggregation |
| Bot responding to mentions | Jetstream | Filter by DID server-side |
| Analytics dashboard | Jetstream | Volume matters, provenance does not |
| Moderation / labeling service | Firehose | You need to prove what an account actually wrote |
| Archival / mirror | Firehose | Need signatures and full protocol events |
| Running your own relay | Firehose | You are the intermediary now |
| Academic dataset with integrity claims | Firehose | Verification is the point |
The Part Everyone Gets Wrong: Reconnection
Whichever you pick, the failure mode that will actually bite you in production is reconnection, not decoding.
- Persist your cursor. Store the last sequence number you successfully processed, durably, not in memory. Restarting without a cursor means silently missing everything that happened while you were down.
- Know your replay window. Relays retain a bounded backlog. If you are down longer than that window, you cannot replay the gap – you need a reconciliation path, not just a reconnect.
- Back off with jitter. When a relay restarts, every consumer reconnects at once. Add jitter or you are part of the thundering herd.
- Handle the stream stalling without disconnecting. A socket that is open but delivering nothing is the nastiest case. Track time since last event and force a reconnect past a threshold.
- Process asynchronously. Never do slow work inline in your message handler. Push to a queue and process separately, or backpressure will disconnect you.
Volume Expectations
Bluesky's network generates a substantial and bursty event stream – steady baseline traffic with sharp spikes during major news, sports and live events. Two consequences for capacity planning:
- Size for peak, not average. The spikes are where consumers fall over.
- Note that event volume tracks activity, not registrations. Bluesky's registered account count keeps climbing past 44 million while daily actives sit far lower – see our May 2026 MAU report. Do not size infrastructure off the registration number.
Can You Skip Both?
Yes, and for many projects you should. If you need trending hashtags or keyword monitoring, running your own stream consumer means operating infrastructure 24/7 to answer a question someone else already answers.
We expose trending hashtags as an API and run Keyword Alerts as a hosted service for exactly this reason. Build the stream consumer when the pipeline is your product, not when it is a dependency.
Frequently Asked Questions
Is Jetstream official?
Jetstream is developed within the AT Protocol ecosystem as a lightweight alternative to consuming the raw firehose. It is widely used in production by third-party services.
Can I filter the firehose server-side?
No. The firehose delivers everything and you filter client-side. Server-side filtering by collection and DID is one of Jetstream's main advantages.
Do I need authentication?
No. Both streams are publicly accessible. You are still expected to reconnect sanely rather than hammering the relay.
What about rate limits?
Streaming is not rate limited the way the XRPC endpoints are – one connection, everything pushed to you. That is precisely why streaming beats polling if you are running into rate limit errors.
Build on Bluesky
- Trending Hashtags API – live hashtag data without running a consumer
- Keyword Alerts – hosted firehose monitoring
- Skyscraper for iOS – see what we built on it