PumpSwap API vs Bitquery: real-time gRPC or historical GraphQL?

Bitquery and a real-time gRPC provider both expose PumpSwap data, but they answer different questions. Bitquery answers "what happened?" with rich GraphQL queries against a full archive. gRPC answers "what's happening right now?" with parsed events delivered the moment a slot lands. If your code makes a trading decision in the next 400ms, gRPC. If your code paints a chart or computes yesterday's PnL, Bitquery.

Bitquery uses a query-credit model. Cheap if your usage is bursty and analytical, expensive if you're streaming continuously and chewing through credits per subscription minute. They publish a free tier; paid plans start in the low hundreds per month and scale into enterprise contracts for high-frequency streaming.

Pricing winner: Bitquery for analytics. NoLimitNodes for predictable bot traffic.

Bitquery's real-time WebSocket and gRPC (CoreCast) endpoints sit behind their indexer. Data flows: validator emits slot, validator pushes to Bitquery's ingestion, ingestion writes to the index, the index fans out to your subscription. That last hop matters. End-to-end latency on Bitquery WebSocket subscriptions tends to land in the 150 to 400ms range depending on query complexity and region.

A direct Yellowstone gRPC subscription cuts the indexer hop. Validator emits, geyser plugin streams, you receive. We measure 12ms p50 from slot landing to your socket on parsed PumpSwap swaps.

The architecture trade is: Bitquery's indexer makes JOINs and historical queries trivial; the same indexer is the latency tax you pay on the live path. There's no way to have both at once on a single connection. Teams that need both pay both.

Latency winner: NoLimitNodes (12ms) and other direct gRPC providers. Bitquery wins on query expressiveness, not on freshness.

You want to write a query, not run an indexer. Bitquery's GraphQL spares you the work of building your own historical store. If you tried to replicate "every PumpSwap pool joined to its Pump.fun graduation event with daily volume buckets" against raw streams, you'd be writing a Postgres pipeline for two weeks. Bitquery gives you a single query.

You need OHLC out of the box. Bitquery exposes candle aggregations natively. You ask for 1m, 5m, 1h candles on any pool and they return. Building that from raw streams means stateful aggregation in your own service.

You're in compliance, research, or quant analytics where end-to-end latency under a second isn't the constraint and full historical depth is.

You want to JOIN across Raydium, Orca, Meteora, and Jupiter in the same query. Bitquery's schema makes that natural. We don't.

You're trading. Snipers, MEV searchers, copy-trade bots. Anything where the difference between landing and missing the trade is measured in slots. The 150-to-400ms aggregator tax on Bitquery is fatal here.

You want flat, predictable cost. $49 or $199 per month, no per-event meter, no surprise bills when memecoin Tuesday hits and PumpSwap volume 10x's.

You're fine doing your own analytics on top. You'll pipe the gRPC stream into Postgres, ClickHouse, or Kafka, and you're comfortable owning that pipe.

You need slot-level transaction context. Raw gRPC gives you the entire transaction with all instructions, not just the parsed event. That matters when you're reasoning about Jito bundles, priority fees, and inclusion order.

We don't compete with Bitquery on analytics. They're better at it. We compete on flat-priced parsed gRPC for the live trading loop, with a 10x price guarantee against like-for-like quotes. PumpSwap, Pump.fun, Raydium, Orca, Meteora, Jupiter, and the Solana system events all sit in our catalog as parsed streams. Pick two on Pro, twenty on Ultra.

The realistic stack we see at customer shops is: NoLimitNodes (or Helius LaserStream) on the live execution path, Bitquery on the analytics path. Trying to make one tool do both jobs is where teams burn weeks.

See the full PumpSwap product on the PumpSwap Enhanced Stream page. The bonding-curve side lives at Pump.fun Enhanced Stream.