Triton One's Cloudbreak Cuts getProgramAccounts Latency 99% With Postgres-Indexed Account Storage

getProgramAccounts is one of the most expensive calls on any Solana RPC node. Triton One Triton One's new Cloudbreak architecture reduces its average latency from 1,725ms to 4ms for small responses, a 99%-plus improvement, while cutting the cost of running a dedicated full-index node from over $3,000 per month to approximately $400. The project is open-sourced under AGPL and live on every Triton endpoint.

Why getProgramAccounts Was Always a Scan

Solana's getProgramAccounts (gPA) asks a node to return every account owned by a given program — open orders on a DEX, all token accounts for a mint, every position in a lending protocol. The validator's built-in account store, AccountsDB, was purpose-built for transaction execution: fast single-account lookups at massive parallelism. It was never designed to answer set queries.

There is no native on-chain grouping of accounts by program owner. Without a dedicated index, a node must scan every one of the 1.1 billion accounts on the chain, test whether owner == P, and load each matching account from a potentially scattered disk location before applying any memcmp or dataSize filters. A program that owns five million accounts costs five million loads per request, regardless of how many accounts actually match the filter.

Solana does include three built-in native indexes (program-to-accounts, mint-to-token-accounts, wallet-to-token-accounts), but enabling them on Agave requires validator-class hardware, roughly 256 GB of RAM per index held entirely in memory, a startup flag, and a full node restart to rebuild. Building an index for anything else (the bytes a memcmp targets, a custom field offset) requires patching the validator client itself. That hardware and engineering overhead has kept fast indexed reads out of reach for most teams, with shared RPC providers generally rate-limiting or blocking gPA outright.

How Cloudbreak's Architecture Changes the Math

Cloudbreak decouples account serving from the validator entirely. It runs three separate services around a Postgres database that holds the latest version of every account on chain.

Data ingestion runs through an indexer that bootstraps from an accounts snapshot, then subscribes to a Dragon's Mouth gRPC stream to stay current at confirmed commitment. Every account update writes a new row into Postgres. Once all of a slot's accounts are written, the indexer advances a readable-slot marker so the query layer always sees complete data.

The schema introduces two structural choices that change query complexity. Both the snapshot table and the live table are partitioned by program owner, with the (owner, pubkey, slot) primary key keeping a program's accounts contiguous within its partition. A gPA for program P drops all other partitions before touching any data. Token program rows additionally extract mint and owner wallet into stored columns at write time and index them directly, so standard token queries become a direct index lookup.

Dynamic indexing is handled by a query tracker that watches every incoming gPA filter shape and issues a CREATE INDEX once a pattern crosses a configured threshold. Index creation runs one at a time, ten seconds apart, and pauses when ingestion lags to avoid competing with writes. Postgres maintains every index through subsequent inserts automatically.

On top sits a stateless JSON-RPC query layer. Each request becomes a single SQL statement that unions the live and baseline tables, resolves the latest version of each account, and streams rows back as they are read. There is no response-size cliff because the server does not buffer the full result before returning it. For jsonParsed responses, all mint lookups are batched into a single pass rather than issued one by one.

Cloudbreak vs. Agave: Latency Benchmarks Across Response Sizes

The following figures come from Triton One's published benchmark table, measured end-to-end within a single datacenter to isolate query latency from network transport.

For base64 getProgramAccounts, Cloudbreak averages 4ms on responses in the 1–10KB range versus 1,725ms on Agave. The gap narrows for very large responses: at 200–500MB, Cloudbreak averages 564ms against Agave's 2,005ms. The critical difference for most dApp use cases is at the lower end, where the typical filtered gPA (a DEX fetching one user's open orders, a wallet loading its token positions) returns a small result set and was paying the full scan cost on Agave regardless.

For jsonParsed responses, the improvement is even more pronounced at small sizes: 4ms on Cloudbreak versus 5,592ms on Agave for sub-1KB results.

What Cloudbreak Means for dApps Hitting gPA Rate Limits

For teams that depend on gPA, the options have historically been to accept rate limits on shared RPC, pay for a dedicated node, or restructure their data model around getTokenAccountsByOwner. Cloudbreak offers a third path: a self-hosted Postgres-based instance with adaptive indexes that build from live traffic rather than requiring upfront schema decisions.

Because indexes are created from observed query patterns, a team can start with a light footprint covering only the programs they query and expand naturally as traffic grows. The modular architecture also means a single Dragon's Mouth stream can feed multiple database instances, and a single Postgres can serve multiple stateless API layers, scaling each independently.

This is the second significant open-source infrastructure release from Triton One in three days. On June 17, the company published SuperBank, a ClickHouse-backed historical ledger layer that delivers 38x faster signature status lookups versus BigTable. Both releases sit within the same RPC 2.0 initiative. The full Cloudbreak pipeline is available under AGPL in the solana-rpc organization on GitHub.