Running Thousands of Websockets for Real Time Prices, Chart on Solana

Price charts are a core tool in any trading application, and charts are built using OHLCV(Open, High, Low, Close, Volume) data.

In addition, real-time charts are foundational for almost every modern crypto application. From DEX terminals and token analytics dashboards to trading bots and price monitoring systems, builders rely on accurate, live candlestick graphs to function at scale.

Today, there are several infrastructure providers offering charting data (OHLCV) on-chain tokens.

In this article, we’ll look at how two commonly used platforms, Birdeye and Bitquery, approach the problem of streaming OHLCV data, especially when the requirement is monitoring a large number of tokens in real time.

The goal here is to understand how different architectural choices affect scalability, cost, and developer experience.

One of the most important differentiators between crypto data infrastructure providers is not just what data they offer, but how flexibly that data can be streamed and consumed.

Birdeye follows a more token-centric streaming approach, where each OHLCV stream is typically configured for a single token or pair. 

This model works well for focused use cases like individual token pages or lightweight tracking, but it naturally scales by increasing the number of streams as token coverage grows.

Bitquery takes a more flexible and expansive approach to streaming. Instead of limiting streams to individual tokens, Bitquery streams are designed to adapt to different levels of market coverage. 

With Bitquery, you get both options. Bitquery also allows you to have thousands of websockets and also allows you to have a single stream can be configured to:

• Stream everything on-chain that matches a query
• Stream tokens or pairs from a specific DEX or multiple DEXs
• Stream all tokens launched via a token launcher platform
• Stream data across an entire blockchain network
• Stream broader trading activity that is not constrained to a single network

This flexibility extends beyond what is streamed to how it is consumed. Developers can choose to ingest data via WebSocket streams for real-time applications or use Protobuf Kafka streams for high-throughput, enterprise-grade systems.

Just as importantly, Bitquery allows teams to decide whether they want to:

• Consume everything through a single, comprehensive stream, or
• Scale horizontally by increasing the number of streams similar to birdeye, depending on the application architecture

This range of options gives builders more control over system design and makes it easier to adapt as products grow from small prototypes into full-scale market infrastructure.

As applications grow, pricing models become just as important as functionality.

Birdeye pricing is based on Compute Units (CU). For streaming data, usage is calculated using CUPB (Compute Units Per Byte), with each delivered message averaging around 150 Bytes. As message frequency increases or more streams are added, costs scale accordingly.

Bitquery on the other hand, offers multiple pricing approaches, each designed to support different stages of product development while keeping costs predictable. 

At one end of the spectrum, developers can purchase fixed-price streams that stream complete market data without worrying about the cost changing based on data volume. 

Whether a stream delivers data for thousands of tokens or an entire network, the pricing remains the same.

Both WebSocket streams and Kafka streams support this model, allowing teams to:

• Build and scale backend infrastructure independently of Bitquery
• Handle increasing data inflow without pricing surprises
• Maintain consistent costs even as token coverage expands

For teams that prefer not to manage large backend ingestion pipelines, Bitquery also supports a more horizontally scalable model, where applications grow by adding more Websocket streams. This makes it easier to start small and expand incrementally while still benefiting from predictable pricing.

Understand Birdeye vs Bitquery pricing with an example

To clearly understand how pricing models differ in practice, let’s walk through a concrete, production-style example.

Assume you want 1-second OHLCV data (the building block of candlestick charts) for all tokens launched on Pump.fun. For simplicity, we’ll assume:

• 1,000 active tokens
• 1 trade per second per token
• ~150 bytes per stream message**
• 31,536,000 seconds per year

Pricing with Birdeye

Taking Birdeye’s Business (B-50) tier for reference,the highest publicly documented plan with clearly defined parameters,the pricing works as follows:

• Base price: $2,300 per month
• Included usage: 500 million Compute Units (CU)
• CUPB (Compute Units per Byte) for OHLCV: 0.003
• Cost per additional: 1M CUs at $3.5

Hence, the Compute Unit consumption turns out:

After subtracting the 6 Billion CUs included in the plan, the remaining 8.19 billion CU are billed as overage. At $3.5 per 1M CU, this results in an overage cost of roughly $28,665.

Total annual cost (with Birdeye) = Base price($2,300)*12 + Overage charges(~$28,665)

    ≈ $56,265 per year

While Birdeye does offer custom enterprise plans, any pricing improvements there are typically incremental.

With Bitquery, the same use case is handled using a single stream. By applying a filter for all Pump.fun token trades, Bitquery can stream 1-second OHLCV data for every matching token through one market-wide stream.

Pricing with Bitquery

Annual cost with Bitquery is fixed because you consume all tokens in 1 single stream. And there are no limits on data pushed.

Bitquery’s price does not change based on:

• Number of tokens
• Trade frequency
• Message volume
• Total data throughput

Fundamental Difference between the Pricing Models

This example highlights a fundamental contrast in pricing philosophy:

• Birdeye’s costs are directly tied to data volume, making large-scale, real-time OHLCV streaming increasingly expensive as ecosystems grow.
• Bitquery decouples pricing from volume, allowing applications to scale token coverage and activity without introducing cost volatility.

For fast-growing environments like Pump.fun, where both token count and trading activity can change rapidly, fixed-price, market-wide streams such as the ones provided by Bitquery serve as a far more predictable and sustainable foundation for long-term product development.

Taken together, these options and calculations mean Bitquery pricing is not just about cost, it’s about flexibility. 

Teams can choose the model that best fits their technical capabilities and growth plans, while remaining confident that scaling their application won’t force a redesign of their data strategy or budget.

Bitquery lets you run thousands of concurrent data streams using a simple per-stream, per-minute pricing model. Instead of charging based on the volume of data pushed, Bitquery only counts how long each stream runs and bills you purely on stream-runtime minutes.

Birdeye primarily uses REST APIs, which return predefined responses. While straightforward, this can limit flexibility when applications need additional metrics or custom aggregations.

Bitquery uses GraphQL, allowing developers to customize responses by modifying the OHLCV stream itself. Alongside OHLCV data for a given time interval, it’s possible to include price change, number of trades, buy vs sell counts and volume breakdowns in the same time interval. Other than the GraphQL Websocket streams, Bitquery also provides Protobuf Kafka Streams as a data solution, which is more of an enterprise grade, scalable and high throughput streaming option.

This level of control can reduce the number of requests required and makes it easier to evolve product features without changing infrastructure.

When building real-time trading systems, latency and time granularity are critical, especially if your use case requires you to generate or monitor 1 second candle stick charts. 

Between both the data providers,  Bitquery provides 1-second OHLCV streams across all supported chains, whereas Birdeye currently provides 1-second OHLCV only for Solana.  For cross-chain applications, this difference directly impacts architectural choices.

To evaluate real-world performance, we ran a simultaneous benchmark using 1-second OHLCV streams under identical conditions (local laptop, same network, same token, same time window). The benchmark software is available here.

Latency Calculations

Both providers were normalized to the same 1-second interval start timestamp to ensure fair comparison.

Benchmark Results

After running the test for a sustained period, the averaged results were:

Insights

• Bitquery delivered 1-second OHLCV updates roughly 1.66 seconds after interval start on average, which means Bitquery delivered the candle stick data 0.67 seconds after candle stick was completed.
• Birdeye delivered updates roughly 2.3 seconds after interval start on average in the tested environment, meaning that candle stick data was delivered after 1.3 seconds of candle completion.
• This represents an approximate 700 milliseconds difference in average latency.
• The delay by Birdeye stream is too big to be ignored by applications that work under seconds timeframe, as a delay of more than 1 second implies the application is always one candle behind when making decisions.

However, for teams that are operating at a very large scale or want data to be delivered in milliseconds of latency both solutions might seem redundant. 

Fortunately for these businesses, Bitquery offers enterprise streaming options such as Protobuf Kafka streams, which can be useful for high-throughput or institutional-grade data ingestion, an option not commonly available across all market data providers.

When tried against the Bitquery Websocket stream the Kafka stream was 500 milliseconds faster, meaning that it will return the same 1 second candle after 0.1 seconds after the candle was completed.

For latency-sensitive applications such as DEX terminals, trading bots, or real-time token monitoring tools, this measurable difference can materially affect responsiveness and execution timing. As always, teams should run independent benchmarks in their own environment, but under identical testing conditions, the latency gap was clearly observable.

For many applications, such as token scanners, launchpad monitors, or auditing tools, data coverage and reliability can be more important than latency.

To evaluate real-time coverage, we ran a benchmark comparing:

• Birdeye WebSocket Stream
• Bitquery Protobuf Kafka Stream

The benchmark codebase is available here.

Evaluation Method

To evaluate data reliability, both sources were run simultaneously. For each newly created Pump.fun token received from either source, an entry was made in a coverage.csv file, using the token address as the key. A value of true was marked under a source if the token was received in real time; otherwise, the field was left empty. To start the benchmark, we run the following command:

Now, there is a chance of getting duplicate entries as the three sources are not in sync and can return a newly generated Pump Fun token later. To counter that we have created a script, namely dedupe.js, which can be run using following command:

Note: The test was done on a local machine with the same network on which latency test was performed.

Evaluation Results

After running the test for a period of one hour, the results were:

Insights

The results highlight an important distinction between real-time delivery guarantees and streaming architecture. During the test window, Bitquery’s Kafka stream delivered 100% coverage, with zero missed newly created tokens. In contrast, Birdeye’s WebSocket stream missed 4 tokens during the same period.

Kafka’s architecture is inherently designed for:

• High-throughput ingestion
• Reliable delivery
• Scalable consumption
• Stronger event durability

This makes it particularly well-suited for high-burst environments like Pump.fun, where token creation can spike rapidly within short time intervals. From an infrastructure standpoint, the key takeaways are:

• Bitquery’s indexed data coverage was complete.
• Kafka streaming delivered full real-time coverage in this benchmark.
• Kafka provides stronger delivery guarantees compared to WebSocket-only ingestion paths.

For teams building mission-critical monitoring systems, such as token launch trackers, compliance tools, or automated trading infrastructure, the availability of a Kafka-based streaming option can materially reduce the risk of missed events and improve ingestion reliability at scale.

Both Birdeye and Bitquery serve important roles in the crypto data ecosystem. Birdeye fits well for focused, token-level insights, while Bitquery’s design favors broad, real-time market monitoring with predictable pricing and flexible querying.

When the requirements of the product are streaming OHLCV data for hundreds of thousands or millions of tokens, architectural flexibility and cost predictability, Bitquery streaming models tend to shine.

Ultimately, the right choice depends on what you’re building today, and how large you expect it to become tomorrow.