How much does one chain actually move?
Omniscale is built for the volume problem: a unified index over every Solana transaction, feeding analytics that stay fast as the ledger grows. To understand the engineering, start with the raw scale it has to absorb — read live, straight from the network.
Throughput against the ceiling
Solana's design target is roughly 65,000 transactions per second. Here is where the live rate sits against that ceiling — and the recent peak. The gap is the headroom an index has to be provisioned for, not the load it sees today.
Data at this scale
Half a trillion rows is not a database question, it is an architecture question. This is the shape of the workload Omniscale indexes.
A firehose, not a feed
At ~4,000 transactions a second the network never pauses between 432,000 slots per epoch. Ingestion is continuous; there is no quiet window to catch up in.
History that only grows
Every one of 500B+ confirmed transactions stays queryable forever. Indexes are built once and amortised across billions of reads, never rebuilt from scratch.
Answers in milliseconds
Against a ledger this size, analytics live or die on the index. Pre-aggregated roll-ups turn a whole-chain scan into a lookup — the difference between seconds and minutes.
Where these numbers come from
Transactions, slots and epoch progress are read from Solana JSON-RPC (getEpochInfo, getRecentPerformanceSamples, getBlockHeight). Supply is the current circulating and total SOL. The headline counter extends the last confirmed total by the measured rate, so it climbs between refreshes — then re-syncs to the chain every 30 seconds.
Why the ceiling matters
Live throughput is a small fraction of the 65,000 TPS design target — that is the point. Capacity planning for an index is sized to the ceiling and the peaks, not the average. Build for the quiet minute and the busy one breaks you.