Logo
New RPC users get 35% off their first monthView the offer
RPC Assistant

How do you evaluate the fastest Solana RPC for your workload?

Summary

There is no single fastest Solana RPC endpoint, because latency depends on where your app runs, which methods it calls, and whether it needs WebSocket or archive data. The practical approach is to measure round-trip time from your own region against the methods you actually use, then decide between shared RPC and a dedicated Solana node. OnFinality provides Solana RPC API access and dedicated node infrastructure, so you can start on shared endpoints and move to dedicated capacity when your workload demands it.

How to decide which Solana RPC is fastest for you

"Fastest" is not a fixed property of an endpoint. It is a measurement that depends on four things:

  1. Where your app runs. A node in the same region as your servers will usually beat a node on the other side of the world.
  2. Which methods you call. getLatestBlockhash and sendTransaction behave very differently from getProgramAccounts or getSignaturesForAddress over a long range.
  3. Whether you need WebSocket. Streaming slotSubscribe or logsSubscribe has different latency characteristics than one-off HTTP calls.
  4. Whether you share the endpoint. Shared RPC pools absorb traffic from many users; a dedicated node gives your workload its own capacity.

A quick way to decide:

Your situationWhat to try first
Prototyping, low traffic, no strict latency targetShared Solana RPC over HTTPS
Trading bot or wallet that needs fresh blockhashes fastShared RPC, then benchmark from your region
High request volume, heavy getProgramAccounts or log queriesDedicated Solana node
Real-time subscriptions (slots, logs, account changes)Endpoint with WebSocket support
Compliance or isolation requirementsDedicated node you control

If you are not sure yet, start on a shared endpoint, measure, and only move to dedicated capacity when the numbers justify it. OnFinality offers both Solana RPC API access and dedicated nodes so you can make that transition without changing providers.

What actually makes a Solana RPC fast

Solana produces blocks roughly every 400 ms, so the network itself is not the bottleneck for most apps. The latency you feel usually comes from the path between your code and the validator or RPC node that answers your request.

Key factors:

  • Geographic distance. Round-trip time is dominated by physical distance. A request from Frankfurt to a node in Tokyo adds tens of milliseconds before any processing happens.
  • Node health and load. A node that is behind on the tip or saturated with requests will respond slowly regardless of distance.
  • Method cost. Light methods like getBalance return quickly. Heavy methods like getProgramAccounts scan a lot of state and can take much longer.
  • Connection reuse. Establishing a new TLS connection per request adds overhead. Keep-alive and connection pooling matter.
  • WebSocket vs HTTP. Subscriptions push data to you, which can be faster than polling, but they require a stable connection and reconnect logic.

This is why "fastest Solana RPC" lists that only name providers are not very useful. The right question is: fastest for which methods, from which region, at what volume?

Benchmarking Solana RPC latency from your own environment

Do not trust a latency number measured from someone else's machine. Measure from where your app actually runs.

A simple HTTP timing loop using curl:

# Replace with your own endpoint (shared or dedicated)
ENDPOINT="https://solana.api.onfinality.io/public"

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{time_total}\n" \
    -X POST "$ENDPOINT" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getLatestBlockhash","params":[{"commitment":"confirmed"}]}'
done

Run this from each candidate region and compare the distribution, not just the average. Look at the median and the tail (p95, p99), because tail latency is what hurts trading bots and user-facing wallets.

For a more realistic test, benchmark the methods your app actually calls:

# Heavier method: measure separately
curl -s -o /dev/null -w "%{time_total}\n" \
  -X POST "$ENDPOINT" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[{"commitment":"processed"}]}'

A JavaScript version using fetch and performance.now():

const endpoint = "https://solana.api.onfinality.io/public";

async function timeCall(method, params = []) {
  const start = performance.now();
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  await res.json();
  return performance.now() - start;
}

(async () => {
  const samples = [];
  for (let i = 0; i < 20; i++) {
    samples.push(await timeCall("getLatestBlockhash", [{ commitment: "confirmed" }]));
  }
  samples.sort((a, b) => a - b);
  console.log("median ms:", samples[Math.floor(samples.length / 2)].toFixed(1));
  console.log("p95 ms:", samples[Math.floor(samples.length * 0.95)].toFixed(1));
})();

Run the same script against every endpoint you are considering, from the same machine, at the same time of day. Repeat at peak and off-peak hours.

Shared RPC vs dedicated Solana nodes

Once you have numbers, the next decision is whether a shared endpoint is enough or you need dedicated capacity.

DimensionShared Solana RPCDedicated Solana node
Setup effortConnect and goProvisioning and configuration
Cost modelUsage-based, lower entry pointFixed capacity, predictable for high volume
Latency under loadVaries with other tenantsConsistent for your workload
Heavy methods (getProgramAccounts, log ranges)May be limited or slowerSized to your needs
WebSocket subscriptionsSupported on shared endpointsSupported, with your own connection budget
IsolationShared infrastructureIsolated to your project
Best forPrototypes, wallets, moderate trafficTrading systems, indexers, high-throughput apps

OnFinality's RPC API service covers shared access, and dedicated nodes give you isolated capacity when shared performance is not enough. Check RPC pricing for how the two models compare for your volume.

Chain settings and connection details

For Solana mainnet, the standard connection details are:

SettingValue
Chain nameSolana Mainnet
Native currencySOL (9 decimals)
HTTP RPChttps://solana.api.onfinality.io/public
WebSocket RPCwss://solana.api.onfinality.io/public-ws
Block explorerhttps://explorer.solana.com

A wallet or app network config in JavaScript:

const solanaMainnet = {
  name: "Solana Mainnet",
  rpcUrl: "https://solana.api.onfinality.io/public",
  wsUrl: "wss://solana.api.onfinality.io/public-ws",
  explorer: "https://explorer.solana.com",
  nativeCurrency: { name: "SOL", symbol: "SOL", decimals: 9 },
};

If you are testing before mainnet, use Solana Devnet and request an airdrop from the devnet faucet through your Solana CLI or wallet. Devnet endpoints are separate from mainnet and should not be used for production traffic.

WebSocket subscriptions and why they matter for latency

Polling getSlot or getLatestBlockhash in a tight loop wastes requests and still leaves you behind the tip. Subscriptions push updates as they happen.

// Using the ws endpoint for slot updates
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe",
    params: [],
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.method === "slotNotification") {
    console.log("new slot:", data.params.result.slot);
  }
};

WebSocket connections need reconnect logic and heartbeat handling. If your app cannot tolerate dropped connections, keep an HTTP fallback for critical reads like blockhash retrieval before sendTransaction.

Common failure modes when chasing Solana RPC speed

  • Stale blockhash. If your RPC is behind the tip, sendTransaction fails with an expired blockhash. Fetch a fresh one immediately before signing.
  • Rate limiting on shared endpoints. Heavy polling or large getProgramAccounts calls can hit limits. Batch requests or move to dedicated capacity.
  • Wrong region. A fast provider in the wrong region is slow for you. Always benchmark from your own infrastructure.
  • Ignoring tail latency. A good median with a bad p99 will still cause timeouts. Track both.
  • No failover. If your only endpoint has an incident, your app stops. Configure a secondary endpoint and health checks.

A minimal monitoring probe you can run on a schedule:

#!/usr/bin/env bash
ENDPOINT="https://solana.api.onfinality.io/public"
START=$(date +%s%3N)
RESP=$(curl -s -X POST "$ENDPOINT" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}')
END=$(date +%s%3N)
echo "latency_ms=$((END-START)) response=$RESP"

Alert when latency crosses a threshold or when getHealth stops returning ok.

Key Takeaways

  • "Fastest" Solana RPC is a measurement, not a label. Benchmark from your own region against the methods you actually call.
  • Shared endpoints are fine for prototypes and moderate traffic; dedicated nodes give consistent latency and isolation for high-volume or heavy-method workloads.
  • Use WebSocket subscriptions for real-time data, but keep HTTP fallbacks for critical writes.
  • Watch tail latency (p95, p99), not just the average.
  • Always configure a secondary endpoint and monitor health so a single incident does not take down your app.
  • OnFinality provides Solana RPC API access and dedicated node infrastructure; see supported RPC networks and RPC pricing for details.

Frequently Asked Questions

Is there one Solana RPC endpoint that is always the fastest? No. Latency depends on your region, the methods you call, and endpoint load. Measure from your own environment.

Do I need a dedicated Solana node? Only if shared endpoints cannot meet your latency, volume, or isolation needs. Start shared, benchmark, then scale up.

Does OnFinality support Solana WebSocket? Yes. The Solana mainnet endpoint supports HTTP and WebSocket transports. See the Solana network page for connection details.

How do I test Solana RPC speed quickly? Run a short curl or fetch loop against each candidate endpoint from the same machine and compare median and p95 latency.

What about devnet? Use Solana Devnet for testing and the mainnet endpoint for production. Do not mix them.

Where can I compare provider options? See how to choose an RPC provider for evaluation criteria, and RPC pricing for cost models.

RPC Knowledge Base

Related RPC details

Never Worry about Infrastructure Again

OnFinality takes away the heavy lifting of DevOps so you can build smarter and faster.

Get Started