157 Billion Solana Rows Per Week: How Bitquery Handles the Pump.fun Volume Problem Across Four Delivery Channels

Solana

Pump.fun

Memecoin

DEX

Data Engineering

GraphQL API

Kafka

Cloud Data Dumps

• June 2, 2026

Last week on Solana, Bitquery served roughly 95 million GraphQL queries at a p50 latency of about 120 milliseconds with essentially a 100% success rate, and streamed roughly 157 billion rows across all customer subscriptions, peaking at around 32 billion rows in a single day. The platform holds thousands of concurrent live WebSocket subscriptions per chain. The chain produces more raw events per second than any other in the platform. The customer base running on it is also the most diverse and the most volume-hungry. And the platform serves both halves of that problem from the same data layer.

This article is about how we got there. Solana on Bitquery is an engineering problem we have explicitly solved: sub-second analytical queries on a chain that emits billions of events per week, sustained billion-row-per-day subscription delivery with server-side filter pushdown per consumer, four coordinated delivery channels that share one source of truth, and a cost profile that does not collapse under Pump.fun-scale write rates. This piece explains the problem, shows the numbers from last week's traffic, and walks through the four delivery surfaces that compose the answer.

It is the engineering-credibility companion to the Stellar deposit-detection guide, the Bitcoin deposit-detection guide, and the Tron transfer-index piece.

The Pump.fun Volume Problem

Pump.fun changed what indexing Solana means. The launchpad creates north of a thousand new tokens per day. Each token spawns a pump_amm pool. Each pool draws a tail of curious wallets, sometimes a flash of real trading volume, and almost always a small pile of dust transfers from spam bots and sandwich automation. Wallets that interact with a new token implicitly create new Associated Token Accounts. Every operation multiplies downstream indexer work.

For a team building anything on top of this ecosystem (memecoin scanners, copy-trading platforms, MEV searchers, DEX aggregators, stablecoin payment products, on-chain forensics), the volume math gets ugly fast. Two production Bitquery customers between them ran 88 million Solana DEX-pool lookup queries last week, just to fingerprint the first event on each new pool. Two others between them streamed 17 billion Solana transfer rows in seven days. The full subscription stream across all Solana customers delivered roughly 157 billion rows of filtered, ordered, deduplicated transfer and DEX data to live consumers in the same window.

None of those workloads fit on a single channel. A polling client cannot keep up with subscription-grade freshness. A subscription cannot replay a year of history. A Kafka consumer is the wrong shape for an interactive UI. And no streaming socket on earth makes sense as the way to feed an offline warehouse ETL. Each delivery surface is good at one or two parts of the problem and bad at the others. A production Solana indexer does not pick one. It uses all four for different parts of its pipeline. The engineering that makes this work is the bulk of this article.

What the Platform Actually Delivered Last Week

The numbers below are pulled from V2 API usage analytics for the seven days ending 2026-06-01, filtered to Solana queries and Solana-only subscriptions. They are the audit-trail for the rest of this article.

Metric (Solana, last 7 days)	Value
GraphQL queries served	roughly 95 million
p50 query latency	about 120 ms
p95 query latency	a little under one second
p99 query latency	under four seconds
Sub-second query responses	over 95%
Query success rate	essentially 100%
Subscription rows delivered	roughly 157 billion
Peak day subscription throughput	around 32 billion rows (late May)
Peak sustained subscription rate	more than 370 thousand rows per second (average across the peak day)
Concurrent live subscription sessions supported	thousands per chain
Total subscription sessions over the week	over a million

The latency profile and the success rate represent the platform's steady state for Solana rather than a one-week peak or a bursty headline. That is the engineering claim.

The Four-Axis Problem

Behind the metrics is one technical problem with four faces. Any system serving a Pump.fun-scale Solana workload has to balance:

Latency. How fresh does each event need to be on the consumer side? A sub-second push for live alerts is a different system than an hourly batch file. Both have legitimate consumers. The over-95% sub-second number above is the query-side achievement; the subscription side runs at sub-second push by default for matched events.

Sustained throughput. Billions of rows a day is a different operational shape than millions a day, which is a different shape from ad-hoc lookups. The infrastructure has to absorb peak hours without dropping events and survive the quiet hours without burning idle capacity. Last week's peak day delivered around 32 billion subscription rows; the quiet day delivered roughly 11 billion. The platform served both without throttling.

Historical depth. Live tip for the last few seconds is one thing. The last thirty days is another. Full chain history from genesis is a third. Each implies a different storage layer.

Filter pushdown. Does the filter get evaluated upstream at the ingestion or query layer, or does the customer pay the bandwidth to receive the firehose and filter it themselves? At a sustained few hundred thousand rows a second on the peak day, the difference between server-side and client-side filtering is the difference between a viable product and a wasted connection. The platform evaluates every customer's filter upstream against our own Solana ingestion before any row hits a consumer.

Each of the four delivery channels below resolves a different combination of these axes. The article's central claim is that a Pump.fun-scale workload composes them.

Channel 1: GraphQL Queries

The interactive, pull-based surface. Open the Bitquery GraphQL IDE, paste a query, get an answer in the millisecond range.

The number that matters here is the latency profile. Roughly 95 million Solana GraphQL queries last week at around 120 ms p50 and over 95% sub-second. That throughput across that latency band is what the channel exists to deliver. The right workloads for it are interactive lookups, polling-light loops where the customer drives the cadence, prototyping new query shapes before committing to them in production, and customer-facing API surfaces where end users trigger a fresh read.

The canonical Pump.fun-shaped query on this channel is a pool first-event fingerprint against pump_amm: the customer maintains a list of pool addresses and wants to know, for each one, the first time anything happened in it. The full query shape lives in the Pump.fun API documentation and the broader Solana DEX Pools API reference. At production scale, one team puts more than seven million calls a day through this exact shape against thousands of pool addresses. The channel handles it because each query is a tightly bounded read against a partitioned ClickHouse table sized for analytical scans.

When to pick this channel: a query you can run in well under a second, against a filter that narrows to a small result set, where the request cadence is driven by the customer's product.

Channel 2: WebSocket Subscriptions

The push-based, real-time surface. Open a WebSocket against the same GraphQL endpoint, declare a subscription with the same filter syntax, and the platform pushes matching rows to the connection as they happen on chain.

The numbers that matter here are concurrency and per-subscription filter pushdown. The platform holds thousands of concurrent live Solana subscriptions, each one with its own filter, each one routed independently. Across last week, those subscriptions delivered roughly 157 billion rows in aggregate. Critically, every one of those rows was matched by an upstream filter against our own Solana ingestion, not generated as a firehose and re-filtered downstream. The platform does not broadcast every Solana transfer to every subscriber and ask them to filter; the filter pushdown happens once, at ingestion, per subscription.

The right workloads for this channel are live alerts, dashboards that need sub-second freshness, payment-monitoring hot paths where a delayed credit hurts the product, and any workflow where the customer's question is "tell me when something happens" rather than "what happened up to now."

The canonical Pump.fun-shaped subscription is a filtered Solana transfer firehose. One production deployment streams every successful SPL Token Program transfer where the mint is USDC or USDT. The shape, the SPL Token Program filter, and the full field reference are documented in the Solana Transfers API. That single subscription delivered nearly eight billion rows last week, sustained roughly thirteen thousand rows per second on average and peaked above twenty-seven thousand. The connection stayed open through reconnects; the predicate sat upstream.

When to pick this channel: live freshness matters and the filter is stable. The volume is what it is, but the customer never pays for the rows they did not ask for.

Channel 3: Kafka Streams

The high-throughput, durable, multi-consumer surface. Bitquery publishes Solana data to Kafka topics partitioned by chain, program, or mint depending on the contract. The customer's consumer reads from the topic with its own offset, its own consumer-group semantics, and its own retention policy. Background on the model lives in the Kafka streaming concepts guide; the real-time Solana data via Kafka page walks through the connection setup end to end.

The engineering reason to pick this channel over a subscription is durability and replay. A WebSocket subscription serving more than a billion rows a day works until the consumer's network blips, at which point reconnect logic and offset bookkeeping become the customer's problem. Kafka makes that the broker's problem. The customer commits offsets against a partitioned topic, rewinds the consumer when needed, and lets the broker buffer through downstream backpressure. At Pump.fun-scale throughput, this is the difference between a robust pipeline and a 3 AM page about a stalled socket.

A worked end-to-end example for a Solana sniper-trade pipeline using Kafka is documented in Sniper trade using Bitquery Kafka stream. Teams that need lower-latency validator-side ingestion can also use Bitquery's Solana gRPC.

When to pick this channel: data engineering on the customer side already speaks Kafka; throughput is high enough that subscription reconnect handling becomes its own engineering problem; the team wants replay semantics that do not depend on upstream cooperation.

Channel 4: Cloud Data Dumps

The batch, historical, warehouse-bound surface. Bitquery delivers Solana data as hourly, daily, or monthly dumps to a customer-controlled S3 bucket, Snowflake account, or Google Cloud destination. The customer connects their warehouse to the destination, ingests on their own schedule, and runs downstream analytics against their own schema.

The engineering reason to pick this channel is total cost of ownership for historical and analytical workloads. The same near-eight-billion-row subscription workload referenced above would translate, in dump form, to roughly half a terabyte compressed per week landing in the customer's bucket. The customer's warehouse owns the schema, queries it with whatever latency profile it offers, and does not pay for the live socket. Bitquery ships the data once, deduplicates upstream, and every consumer reads from the same canonical source.

The schema is documented as sample files in the Bitquery cloud-data-dump sample repository under the Solana directory. A data team can pull the sample, validate the shape against their warehouse, and confirm the join keys before any commercial conversation.

For most enterprise Solana workloads (production custodians and exchanges, payments products at scale, analytics platforms with their own warehouse, multi-chain wallets feeding their own backends), this is the default recommendation.

When to pick this channel: downstream analytics live in a warehouse, the workload needs more than thirty days of history, or the volume justifies a dedicated cloud-data agreement instead of paying for the same data through query or subscription pricing.

A Side-by-Side View

Channel	Latency	Sustained throughput (Solana, observed)	Historical depth	Best for
GraphQL query	around 120 ms p50, under a second at p95, over 95% sub-second	roughly 95 million requests over 7 days	Full chain	Interactive lookups, polling-light workloads, prototyping
WebSocket subscription	Sub-second push	roughly 157 billion rows over 7 days, thousands of concurrent sessions supported per chain, several hundred thousand rows per second on the peak day	Live tip + recent window	Real-time monitoring, dashboards, payment hot paths
Kafka streams	Single-digit ms push	Production-scale with durable retention	Live tip with replay	High-throughput downstream pipelines, multi-consumer fan-out
Cloud data dumps	Hourly / daily / monthly	Roughly half a terabyte compressed per week for a USDC and USDT stablecoin slice	Full chain	Warehouse ETL, historical backfill, batch analytics

Five Pump.fun Workload Patterns in Production

Five recurring shapes the platform sees, one line each:

Pool first-event lookup. Token launch detectors and sniper bots polling for the first event on each new pump_amm pool. Shape in the Pump.fun API and the Solana DEX Pools API. Channel: GraphQL query.
First-funding lookup. AML and new-account detection, ordered ascending by Block_Slot and limited to one record per address. Shape in the Solana Transfers API. Channel: GraphQL query.
Smart-money wallet tracker. Copy-trading platforms and memecoin leaderboards watching a curated wallet corpus with DEX-router exclusion. Shape in the Solana Transfers API and the Solana Trader API. Channel: query for small corpora, subscription for larger or always-on cases.
Per-token transfer feed. Token explorers and holder dashboards narrowed by Currency.MintAddress. Shape in the Solana Transfers API; pair with Solana Token Holders for holder-side analytics. Channel: GraphQL query, subscription when a token page needs sub-second updates.
Stablecoin and SPL transfer firehose. Payment monitoring and treasury hot paths streaming the SPL Token Program transfer set filtered to a mint list. Shape in the Solana Transfers API. Channel: subscription at medium scale, Kafka or cloud data dumps at high volume.

Picking the Right Channel

A short decision tree the reader can map their own workload onto:

Need historical data more than thirty days back? Use cloud data dumps.
Need sub-second freshness AND a filter that narrows millions of rows a day down to thousands? Use a subscription.
Need to fan out to multiple downstream consumers with durable replay? Use Kafka.
Doing interactive UI, ad-hoc analytics, or low-frequency polling? Use the GraphQL query channel.
Need both live tip and the last year of history? Use a subscription for the live half and cloud data dumps for the historical half. This is what most production teams running real workloads on Solana actually do.

A custodian credits deposits off a subscription while batch-reconciling treasury off a daily dump. A memecoin tracker polls pool first-events through queries while streaming new pool creation through a subscription. A market-data product feeds its warehouse from Kafka while serving its UI from queries. The four channels are coordinated, not competing.

The Engineering Underneath

The customer-facing claim is the four channels. The engineering claim is everything below them.

Bitquery runs its own Solana node infrastructure. The ingestion layer is owned and operated end-to-end. No dependency on third-party RPC providers, no shared Geyser plugins on someone else's validator, no rate-limited public endpoints sitting in the hot path. Running our own nodes is what makes the rest of this list possible, because every other guarantee in this article depends on having unfiltered access to the chain stream at the validator level.

Filter pushdown happens at ingestion. When a subscription declares Currency.MintAddress: {in: [USDC, USDT]}, that predicate is evaluated upstream against the data coming off our nodes. Only matching rows are routed to that subscriber. With thousands of concurrent Solana subscriptions, each with its own filter, the alternative (broadcast the firehose, let every customer filter it) would be a non-starter. The peak observed Solana subscription throughput of several hundred thousand rows per second on the peak day is the post-filter delivered rate, not the chain rate, and it is delivered per consumer with the rows that consumer asked for.

The analytical engine is partitioned ClickHouse. Multi-billion-row weekly query workloads sit on partitioned tables sized for analytical scans. The roughly 120-millisecond p50 latency at tens of millions of queries a week comes from a combination of pre-decoded schema, partition pruning that limits the scanned range, columnar storage that reads only the columns the query returns, and an analytical engine that was designed for this shape of workload rather than retrofitted to it.

WebSocket multiplexing is per-subscription. The peak concurrent subscription sessions share connection infrastructure, with filter pushdown applied independently per subscription so each socket carries only the rows that subscription matched. Stream-count and rate envelopes are negotiated per customer rather than enforced by a tier ceiling.

Kafka partitioning is by chain, program, or mint. Depending on the contract, the customer's downstream consumers get parallel ingestion at their side rather than a single fat partition.

Cloud data dumps are deduplicated upstream. The per-customer S3, Snowflake, or Google Cloud delivery is shared compute, not per-customer reprocessing. One ingestion pipeline produces the canonical dump; every customer subscription reads from it. This is why migrating a multi-terabyte-per-week subscription workload to a half-terabyte-per-week dump is a cost story for the customer rather than a capability tradeoff.

The essentially-100% query success rate across roughly 95 million weekly calls is the proof. Only a handful of thousands of failed queries out of nearly a hundred million. The platform was not designed to fail and recover at this volume, it was designed not to fail at this volume.

The through-line is that owning the node infrastructure end-to-end is what makes filter pushdown, sustained throughput, full historical retention, and a consistent schema across all four channels possible at the same time. Every other blockchain data layer makes one or two of these tradeoffs explicit because they sit on top of someone else's node infrastructure. Owning the validator-to-warehouse path is what closes the loop.

Summary

A production Solana indexer that wants to keep up with Pump.fun-scale volume has a clean path through Bitquery. Use the GraphQL query channel for interactive lookups and polling-light workloads. Use WebSocket subscriptions for real-time freshness with server-side filter pushdown. Use Kafka for high-throughput downstream pipelines with replay semantics. Use cloud data dumps for warehouse ETL and historical backfill.

Most teams compose more than one. The cleanest production workloads we see use three or four at once, each carrying the part of the pipeline it is best at. The ingestion layer underneath every channel is the same: Bitquery's own Solana node infrastructure, filter pushdown applied at the source, partitioned ClickHouse handling the analytical workload, and a per-channel delivery layer optimised for its specific shape.

Last week we served roughly 95 million Solana queries at about 120 ms p50, delivered roughly 157 billion subscription rows across thousands of concurrent sessions, and ran the whole thing at essentially a 100% success rate. That is what "we have solved this engineering problem" looks like in numbers.

The sample data files and S3 bucket link for end-to-end testing are in the public sample repository under the Solana directory. The Solana streaming, Kafka, and gRPC integration docs live at docs.bitquery.io. For dev exploration, the Bitquery GraphQL IDE runs the query shapes referenced in this article against live Solana data.

Related Resources

Subscribe to our newsletter

Subscribe and never miss any updates related to our APIs, new developments & latest news etc. Our newsletter is sent once a week on Monday.