RidgeDB v2 is a ground-up rewrite of the engine that handles the heaviest Solana account queries on the Solana Tracker RPC: getProgramAccounts, getTokenAccountsByOwner, getTokenLargestAccounts and holder counts. Standard validator RPCs refuse these calls, rate-limit them hard or take seconds to answer. The same engine serves all holder counts and wallet account data in the Solana Data API.
RidgeDB v2 is live now and existing integrations work unchanged. You can also run it on your own dedicated node.
What is RidgeDB v2?
RidgeDB v2 is a purpose-built Solana account store written in Rust, designed around how account data is actually queried. It replaces Ridge v1, which ran on PostgreSQL.
Ridge v1 worked, but a general-purpose database carrying more than a billion Solana accounts hit hard limits:
- The database grew to nearly 5 TB.
- The biggest mints needed a special slow queue. A holder count for USDC could take up to 60 seconds.
RidgeDB v2 vs Ridge v1
| Ridge v1 | RidgeDB v2 | |
|---|---|---|
| Database size | 4.5–4.9 TB | 1.3 TB (about 3.5× smaller) |
| Point lookup (engine) | 31 µs | 3.2 µs (about 10× faster) |
| Paged query (engine) | 60–156 µs | 15–22 µs (4–7× faster) |
| Holder count for USDC, USDT and wSOL | Up to 60 s, in a slow queue | 0.13 ms, all three in one call |
| Freshness | Not measured | 0–1 slots behind the chain |
| New server from zero | — | About 2.5 hours, fully automatic |
| Correctness | Not verified | Verified against Solana's own state hash |
The 2.5 hours covers the engine build only. A full dedicated node order, from purchase to serving traffic, is live within 24 hours.
Solana account queries: production latency
Measured on our production nodes, before network time. At these speeds, what you notice is the network round trip, not the query.
| Method | Median | p90 |
|---|---|---|
getAccountInfo | 0.12 ms | 0.17 ms |
getTokenSupply | 0.12 ms | 0.15 ms |
getTokenHolderCounts (USDC + USDT + wSOL, 21M+ holders) | 0.13 ms | 0.16 ms |
getTokenLargestAccounts (USDC) | 1.4 ms | 1.6 ms |
Indexed getProgramAccounts filters | Under 1.2 ms | |
| Top 50 holders of any token | 3–7 ms | |
| Balances of 250 wallets for one mint, in one call | About 20 ms |
Throughput per node
Load test results for a single node:
| Workload | Throughput |
|---|---|
| Lightweight calls over public HTTPS | 208,000 requests/s |
| Token API mix (holders, balances, supply, largest accounts) | 36,000–58,000 requests/s |
| Mix of all methods, including heavy scans | 3,200–7,400 requests/s |
Full getProgramAccounts dumps | 51,000–64,000 accounts/s |
Our busiest production node has peaked at 15,700 requests per second, a fraction of its capacity. Under 37,000 requests per second of token traffic, the data stays about one slot behind the chain.
Supported RPC methods
All existing Ridge methods are supported and checked against mainnet. Our compatibility suite matched 558 of 558 checks, plus 1,200 accounts and 73,000 token-count rows. Token-2022 accounts, including extensions, remain fully supported.
Standard Solana RPC methods
getAccountInfo,getMultipleAccounts,getBalancegetProgramAccountsgetTokenAccountsByOwnergetTokenAccountBalance,getTokenSupply,getTokenLargestAccountsgetVoteAccounts,getSlot,getHealth,getGenesisHash,getClusterNodes
Ridge extensions
getProgramAccountsV2andgetTokenAccountsByOwnerV2: paginated versions with cursors and exact totals.getTokenAccountsWithCursor: walks every holder of a token, sorted, page by page.getTokenAccountsByOwners: balances for up to 250 wallets in one call.getTokenHolderCounts(new): holder counts for many mints at once, at a guaranteed slot.getLookupTablesByAccount,getLookupTablesByAccounts,getLookupTablesByAuthorityandgetLookupTablesByMint: find address lookup tables.getPrimaryDomain,getMultiplePrimaryDomainsandgetAllDomains: resolve SNS domains.
Live holder-count stream
/stream/holder-counts is new. It pushes holder-count changes as they happen, so you don't have to poll. It matched the batch method on 373 of 373 mints in our tests.
New query features
- Exact totals by default. Paged queries return a
totalCount, so "how many holders does this token have" is one call. excludeZero. Counts only real holders and skips empty token accounts.- Self-building indexes. The first time Ridge sees a new filter shape, it builds an index for it in the background. Later queries of that shape become sub-millisecond lookups instead of scans. Indexes that go unused for 30 days are cleaned up automatically.
- Smarter compression. Large responses use zstd or gzip. Small responses are sent uncompressed, because there compression costs more time than it saves.
How RidgeDB v2 stays fresh and correct
Fast doesn't help if the data is stale or wrong. RidgeDB v2 was built to stay correct and current without anyone watching it.
- Keeps pace with mainnet. Mainnet produces about 46 MB/s of account updates. Ridge ingests them in parallel, so one slow connection can't hold it back.
- Fails over between data sources. If a source fails, or stays connected but starts falling behind, Ridge switches in about 100 ms and switches back once the preferred source recovers. In one real incident it was back to 0 slots behind 26 seconds after a provider began lagging.
- Survives crashes. Every update is durably recorded before it's applied. A killed process is serving again in about 11 seconds without losing a slot. Longer outages are closed automatically from Solana snapshots.
- Verifies state. After every rebuild, Ridge checks the full account state against Solana's own cryptographic state hash. System accounts are continuously audited against mainnet and corrected if they ever disagree.
Dedicated RidgeDB nodes from €749 a month
You can now order RidgeDB v2 as a dedicated node: your own server, running the full Ridge engine, for your traffic only. It costs €749 a month, with 10% off quarterly, 15% off semi-annual and 20% off annual billing. Pay by card or crypto.
- Every method above, with your own API key and HTTPS endpoint.
- No shared rate limits. The whole node's capacity is yours.
- Indexes shaped by your queries. The node builds indexes for the filters your application actually uses.
- Live within 24 hours. Ridge downloads, imports and verifies mainnet state, catches up to the chain and starts serving, all automatically.
- Monitored and maintained by us. Alerts cover lag, crashes, hardware errors and disk health. Updates go out with about 20 seconds of switchover, and we can roll back instantly.
- Deploy worldwide. Choose the region with the lowest round trip to your own infrastructure.
Try RidgeDB v2
RidgeDB v2 is already serving the Solana Tracker RPC, so your existing key works with the new methods. Copy your full RPC URL from the shared RPC dashboard, then run a standard call:
curl "$SOLANA_RPC_URL" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getTokenLargestAccounts","params":["EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"]}'Choosing between shared and dedicated infrastructure? Read how to evaluate Solana RPC providers.
FAQ
Do I need to change my integration to use RidgeDB v2?
No. RidgeDB v2 is already live on the Solana Tracker RPC and existing integrations work unchanged. Your existing key also works with the new methods.
How fresh is RidgeDB v2 data?
It runs 0–1 slots behind the chain, and stays about one slot behind under 37,000 requests per second of token traffic.
How much does a dedicated RidgeDB node cost?
€749 a month, with discounts of up to 20% on longer billing cycles. See dedicated node pricing.
How long does a dedicated RidgeDB node take to deploy?
It's live within 24 hours. Ridge downloads, imports and verifies mainnet state, catches up to the chain and starts serving automatically.
How do I count only real token holders?
Use excludeZero, which skips empty token accounts. Paged queries return the result as totalCount.
How is RidgeDB v2 data verified?
After every rebuild, Ridge checks the full account state against Solana's cryptographic state hash. System accounts are also audited against mainnet continuously.