How do Solana RPC provider pricing tiers actually work?

Solana RPC pricing looks simple on a landing page — a free tier, a monthly plan, and a "contact us" button — but the numbers that decide your bill are usually buried in compute unit (CU) accounting, per-method multipliers, and rate limits. If you are comparing providers for a production app, the tier name matters far less than what the tier actually meters.

This page explains how Solana RPC pricing tiers are typically structured, what each tier is realistically good for, and which questions to ask before you commit. It is written for developers and infrastructure buyers who need to map a workload to a plan, not just read a price list.

Quick recommendation: which tier fits your workload

Before comparing vendors, classify your workload. Solana RPC pricing is not linear, and the same plan can be cheap for one app and expensive for another.

If you are unsure, start on a metered plan, instrument your CU usage per method, and only move to a committed or dedicated tier once you can forecast monthly consumption. OnFinality publishes its RPC plan structure on the RPC pricing page, and the Solana network page covers endpoint and transport details.

What Solana RPC providers actually meter

Almost every Solana RPC provider prices on some combination of the following. Knowing which one dominates your workload tells you which tier you need.

Request count. The simplest metric: number of JSON-RPC calls per month. Cheap for getSlot and getLatestBlockhash, but misleading for heavy methods.

Compute units (CU). Solana assigns a CU cost to each RPC method, and many providers multiply that by a per-method weight. A single getProgramAccounts call can cost orders of magnitude more than a getBalance. If a provider advertises "unlimited requests" but meters CU, your effective ceiling is CU, not requests.

Bandwidth and response size. Large account scans and log streams return big payloads. Some providers cap egress or count bytes into the CU calculation.

Concurrency and rate limits. Requests per second (RPS) or concurrent connections. This is often the real constraint during traffic spikes, even when monthly volume looks fine.

Feature access. Archive data, getProgramAccounts with filters, WebSocket subscriptions, and priority fee APIs are frequently gated to higher tiers.

When you read a pricing page, translate every bullet into one of these five categories. If a provider does not state how CU is calculated, ask before you commit.

The four tiers you will see, and what they are for

Free and public tiers

Free tiers exist to get you building. They usually include a daily or monthly request cap, aggressive rate limits, and no guarantee of availability. Public endpoints — including the OnFinality public Solana endpoint — are fine for wallets, scripts, and testnet work, but they are shared and not designed for sustained production traffic.

Use free tiers to validate integration, not to serve users.

Pay-as-you-go tiers

Metered plans bill per request or per CU with no monthly commitment. They are the right default for early production because they absorb unpredictable growth without a contract. The tradeoff is that unit prices are higher than committed plans, and you can still hit rate limits during bursts.

Committed or subscription tiers

These plans bundle a monthly CU or request allowance at a lower unit rate, sometimes with overage pricing. They suit apps with predictable traffic. The risk is over-provisioning: if you buy 500M CU and use 120M, you paid for headroom you did not need. Buy committed tiers only after you have at least one full month of metered data.

Dedicated node tiers

Dedicated infrastructure gives you a node (or cluster) that is not shared with other customers. Pricing is usually a flat monthly fee per node, sometimes with add-ons for archive, higher RPS, or additional regions. This is the tier that trading systems, indexers, and high-throughput dApps converge on because it removes noisy-neighbor effects and gives predictable latency. OnFinality's dedicated node offering follows this model.

How to compare two Solana RPC quotes

Headline prices are not comparable across providers because the metering differs. Normalize before you decide.

A practical method: take one week of production traffic, replay it against each provider's metering rules, and compare the resulting monthly figure. That number is the only one worth comparing.

Reading a Solana RPC pricing page without getting misled

A few patterns show up repeatedly.

• "Unlimited requests" with CU caps. The request count is unlimited; the CU budget is not. Check the CU allowance.
• Free tier with a low RPS ceiling. Fine for development, unusable for a wallet with real users.
• Dedicated pricing quoted per node, not per request. Compare against your metered spend, not against another provider's subscription tier.
• Add-ons listed separately. Archive, trace, and additional regions are common upsells. Add them before comparing totals.

If a provider does not publish CU weights, treat the pricing page as incomplete and request the method-level breakdown.

Estimating your monthly Solana RPC cost

You do not need a perfect model — you need a defensible one. Start by logging method-level call counts for a representative period.

# Example: count method calls from an RPC access log over one day
# (adjust the log path and pattern to your setup)
grep -o '"method":"[a-zA-Z]*"' rpc-access.log \
  | sort | uniq -c | sort -rn | head -20

Once you have the distribution, apply each provider's CU weights and multiply by their unit price. Then add the fixed costs: committed plan fee, dedicated node fee, and any add-ons. The sum is your comparable monthly cost.

A useful sanity check is to compute cost per 1,000 getProgramAccounts calls and cost per 1,000 sendTransaction calls separately. Those two numbers usually reveal which provider is actually cheaper for your app.

When a dedicated Solana node is cheaper than a metered plan

Metered plans look cheap until a single workload dominates your bill. Two cases flip the math:

1. Indexers and analytics. Backfilling program accounts or scanning historical signatures can consume a month of CU in a day. A dedicated node with archive access is usually more predictable.
2. Trading and latency-sensitive services. When p99 latency matters, shared tiers introduce variance you cannot control. A private endpoint removes that variable.

If either describes your workload, price a dedicated node before you scale a metered plan. OnFinality's Solana RPC and dedicated node options are designed for these cases, and the RPC pricing page lists the plan structure.

Connecting to a Solana RPC endpoint

Whatever tier you choose, the connection pattern is the same. Here is a minimal JSON-RPC call against a Solana endpoint:

curl https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

For subscriptions, use a WebSocket endpoint:

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "logsSubscribe",
    params: [{ mentions: ["<PROGRAM_ID>"] }, { commitment: "confirmed" }]
  }));
};

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  if (msg.method === "logsNotification") {
    console.log(msg.params.result.value.signature);
  }
};

When you move to a paid or dedicated tier, swap the public URL for the endpoint your provider issues. Keep the transport (HTTP vs WebSocket) consistent with what the plan supports.

Monitoring signals that tell you to change tiers

Do not wait for a bill to tell you the plan is wrong. Watch these signals:

• 429 responses. You are hitting rate limits; either raise the tier or reduce burst concurrency.
• Rising CU per request. A new code path (often getProgramAccounts) is inflating cost.
• p95 latency drift. Shared tiers degrade under load; a dedicated node stabilizes it.
• Overage charges. If you exceed your committed allowance two months in a row, re-tier.
• WebSocket disconnects. Subscription limits or idle timeouts may be the cause.

Instrument these before you scale, not after.

Key Takeaways

• Solana RPC pricing tiers are usually defined by request volume, compute units, rate limits, and feature access — not by the tier name.
• Free and public tiers are for development; metered plans suit early production; committed plans suit predictable traffic; dedicated nodes suit high-throughput, latency-sensitive, or archive-heavy workloads.
• Normalize quotes by replaying real traffic against each provider's CU weights before comparing prices.
• Watch 429s, CU per request, latency drift, and overage charges to decide when to change tiers.
• OnFinality offers Solana RPC and dedicated node options; see RPC pricing and supported RPC networks for current details.

Frequently Asked Questions

Is a free Solana RPC tier enough for production? Usually not. Free tiers are shared, rate-limited, and lack availability commitments. They are appropriate for development and low-stakes scripts.

Why do two providers quote very different prices for the same app? Because they meter differently. CU weights, per-method multipliers, and rate limits vary, so the same traffic can cost very different amounts.

When should I move from a metered plan to a dedicated node? When a single workload (archive scans, getProgramAccounts, or latency-sensitive trading) dominates your bill or your latency variance, or when you consistently hit rate limits.

Do I need archive access? Only if you query historical slots, backfill data, or run analytics. Many production dApps do not need it; indexers and analytics tools usually do.

How do I forecast my monthly cost? Log method-level call counts for a representative period, apply each provider's CU weights, multiply by unit price, and add fixed plan and add-on fees.