Solana RPC infrastructure differs from Ethereum's in three load-bearing ways: reads are governed by commitment levels instead of block tags, the hardware floor for running your own node is an order of magnitude higher, and a handful of account-scanning methods dominate cost and reliability in a way EVM developers do not expect. If you arrive with Ethereum habits — "we'll just run a node," "default read settings are fine," "logs queries are cheap" — each one will bite. This guide walks through what actually transfers, what does not, and how to choose infrastructure for a Solana workload on purpose.
What transfers from the EVM world, and what does not
The surface layer feels familiar. Solana's RPC is JSON over HTTP for request-response and WebSocket for subscriptions, exactly the split covered in our WebSocket vs HTTP guide. Solana's documentation describes the API as providing "methods to read network state, send transactions, simulate execution, and subscribe to live updates" — functionally the same jobs as their EVM counterparts, and general concepts from our RPC and node infrastructure primer apply unchanged.
Below the surface, the data model diverges hard. Solana has no EVM-style event logs with indexed topics. Programs (Solana's contracts) are stateless; all state lives in accounts that programs own and modify. Where an Ethereum indexer filters logs by topic, a Solana consumer either scans accounts by program and byte-pattern, parses transaction histories, or subscribes to account changes. Method names reflect this: getAccountInfo, getProgramAccounts, getSignaturesForAddress, accountSubscribe. None of your eth_getLogs mental math survives the trip.
Two operational facts complete the picture. First, Solana produces blocks in roughly 400 milliseconds, not 12 seconds — about 30 times faster — so anything rhythmically tied to blocks (polling, per-block caching, "wait one block" logic) operates at a different frequency. Second, the public cluster endpoints are explicitly not for building on: as the docs put it, "public RPC endpoints are shared infrastructure and are not intended for production applications." They rate-limit aggressively, and every Solana tutorial that hardcodes the public mainnet URL is teaching a setup that falls over at the first real user.
Every Solana read method accepts a commitment parameter with three values, and choosing it is not optional hygiene — it decides what "true" means for your app.
- `processed` — the node's most recent block. Fastest, and can still be rolled back.
- `confirmed` — a block that received votes from a supermajority (over two-thirds) of stake. In practice the workhorse level: fast and very rarely reorged.
- `finalized` — a block with maximum lockout, which the cluster recognizes as final. Slowest but irreversible; also the default when you omit the parameter.
The classic mistake is mixing levels without noticing. Your app submits a transaction, confirms it at confirmed, then refetches the balance at the default finalized — and the balance appears unchanged, because finalization lags confirmation by many slots. The app looks broken; the infrastructure is fine. The discipline that prevents this: pick one commitment level per user-facing flow and pass it explicitly on every call in that flow. Use confirmed for interactive UX, reserve finalized for irreversible business actions (crediting a deposit, releasing goods), and treat processed as a specialist tool for latency-critical displays that can tolerate flicker.
There is no equivalent decision on Ethereum reads — you mostly query latest and think about reorg depth rarely. On Solana the parameter is on every method for a reason, and teams that standardize it early skip a whole class of ghost bugs.
A concrete example makes the stakes obvious. Suppose a swap interface reads a user's token balance at processed to feel snappy, and the slot it read from gets skipped — a normal event, not a failure. The interface briefly showed tokens that, from the cluster's final point of view, never arrived. If the interface only displays that number, nobody is harmed; the next read corrects it. If it acts on that number — enabling a withdrawal button, sizing a trade — you have built a race condition into the product. The rule that falls out: commitment level should be chosen per consequence, not per screen. Reads that gate irreversible actions get finalized; reads that inform the user get confirmed; reads that decorate the UI can get processed if latency genuinely matters there.
The hardware cliff: why "just run a node" usually stops here
On Ethereum, a capable full node runs on hobbyist hardware — a 1.2TB NVMe minimum per Reth's published requirements. Solana's equivalent numbers, from Anza's validator documentation, are in a different class entirely: processors at "2.8GHz base clock speed, or faster" with modern instruction sets, and for RPC use specifically "12 cores / 24 threads, or more" with "256GB or more" of RAM — rising to "512 GB or more" when all account indexes are enabled. Storage guidance calls for separate high-endurance NVMe drives, with accounts and ledger explicitly not sharing a disk on RPC nodes, because the sustained write load devours both IOPS and drive lifespan.
The disk budget is its own line item. Anza's guidance calls for on the order of a terabyte or more of high-endurance NVMe for the accounts database, a comparable allocation for the ledger, and hundreds of gigabytes more for snapshots — as separate drives, not partitions, because accounts and ledger writes contend for the same IOPS when co-located. Consumer SSDs are explicitly the wrong tool: the sustained write volume chews through drive endurance ratings that would last years under desktop use. Budget for enterprise-class drives and plan to replace them, the way a fleet operator budgets for tires.
That is not a spare-server spec; it is a five-figure machine or a serious monthly dedicated-server bill, before you staff the on-call. The chain's throughput is the reason: hundreds of millions of accounts churning at 400ms cadence produces a firehose of state writes that modest hardware physically cannot absorb. And unlike Ethereum, there is no meaningful "light" middle ground for serving applications — an RPC node that lags the cluster is not a slightly stale node, it is a broken one, because slots keep arriving whether you have kept up or not.
The consequence shapes the whole ecosystem: the practical default on Solana is hosted RPC, even for teams that would self-host on Ethereum without a second thought. Running your own Solana RPC node is a deliberate product decision for indexers and trading firms, not a cost-saving move — the arithmetic in the comparison table below makes that concrete.
More in Node & RPC Infrastructure
The expensive methods: where Solana RPC bills and outages actually come from
A small set of methods produces most Solana RPC pain, and knowing them by name is half the defense, because each one has a cheaper pattern that replaces it.
`getProgramAccounts` scans every account owned by a program, optionally filtered by size and byte patterns. For a large program — a DEX, a lending market, an NFT standard — that is millions of accounts per call. It is the single most restricted method across hosted providers: some cap it, some price it punitively, some disable it outright. If your architecture refreshes state by calling it on a timer, you have built your product on the one method the ecosystem is actively trying to stop you from calling. The sustainable patterns are: call it rarely to bootstrap, then maintain state incrementally via accountSubscribe; or consume a purpose-built indexing pipeline instead of raw RPC scans.
`getSignaturesForAddress` plus per-transaction fetches is the standard way to reconstruct history, and it is a request-multiplier: one address's history means one signature-list call plus one getTransaction per signature. Wallet-history features that feel free on EVM chains (one logs query) become thousands of calls. Batch, checkpoint, and cache aggressively — the request-shaping techniques in our rate limit guide apply directly, and on Solana you will need them sooner.
Account subscriptions at scale are the good news: accountSubscribe and programSubscribe push state changes over WebSocket, and they are the intended replacement for the polling and scanning patterns above. The engineering cost is the usual subscription tax — reconnection, resubscription, gap healing — paid at Solana's message rates rather than Ethereum's.
A worked comparison shows how the same feature diverges across chains. "Show this wallet's token balances, live" on Ethereum is a handful of contract calls plus a logs filter. On Solana done naively, it is a getTokenAccountsByOwner call re-polled every few seconds — burning quota 30 times faster than an equivalent per-block poll on Ethereum would. Done well, it is one initial fetch plus one accountSubscribe per token account, after which the network pushes changes and your steady-state request count drops to almost zero. Same feature, an order-of-magnitude cost difference, decided entirely by whether the developer knew the platform's intended pattern. That knowledge gap — not raw prices — is where most surprise Solana RPC bills come from.
Your realistic options, compared
The honest comparison is cost against the workload class, with a derived column showing what each dollar actually buys. Hosted figures use QuickNode's published plans (free tier: 10M credits and 15 requests/second; Build at $49/month) as a representative baseline; self-hosting assumes a machine meeting Anza's RPC spec at typical dedicated-server pricing.
| Option | Monthly cost | What it handles | Effective cost per always-on workload | Breaks down when |
|---|---|---|---|---|
| Public cluster endpoints | $0 | Tutorials, one-off scripts | n/a — rate-limited on purpose | Any production traffic |
| Hosted free tier | $0 | Prototypes, low-traffic dapps | $0 while under quota | Sustained polling or any scanning method |
| Hosted paid plans | $49–999+ | Most production dapps and bots | Tens of dollars per steady workload | Heavy getProgramAccounts, full-history indexing |
| Your own RPC node | Roughly $500–1,500+ (server) plus operations | Unmetered scanning, tracing, indexing | Cheapest per call only above ~millions of calls/day | Team cannot staff 24/7 node operations |
Read the last column as the decision driver. Choose hosted RPC if you are building a dapp, bot, or backend with normal read/write traffic — this is the Solana default, not a compromise. Choose a specialized indexing provider if your need is really "query program state like a database" — that product category exists precisely because raw getProgramAccounts does not scale as an API. Choose your own node if unmetered scanning or full-history replay is your product and you can fund the hardware and the on-call rotation. Skip self-hosting if the motivation is saving the $49–999 hosted bill; the server alone costs more before the first engineer-hour is spent.
Situation 1: An EVM team shipping its first Solana feature
You have a working Ethereum dapp and are adding Solana support, planning to mirror your existing architecture. Budget the port realistically: the RPC transport layer carries over, but every data-access pattern needs rethinking — logs-based features become account-subscription or history-parsing features, and your indexer's schema likely changes shape. Start on a hosted provider's free tier, standardize confirmed commitment across the app on day one, and audit for any accidental getProgramAccounts on a hot path before launch. The porting effort lives in the data model, not the connection code.
Situation 2: A trading bot where 400ms slots are the opportunity
Solana's speed is why you are here: opportunities appear and vanish inside a slot or two. Use processed commitment for market-state reads with explicit handling for the occasional rollback, subscriptions rather than polling for everything, and a paid plan sized for message volume — free-tier rate ceilings are incompatible with slot-speed reaction. Dedicated or colocated infrastructure enters the conversation here not to save money but to cut queueing latency; that is the same logic as low-latency EVM setups, with the clock running 30 times faster.
Situation 3: An analytics or portfolio product reconstructing account history
Your product answers "what happened to this wallet / protocol over time," which on Solana means signature walks and transaction parsing at scale. Do the multiplication early: accounts × average signatures × one fetch each, at your refresh cadence. If the number lands in the tens of thousands of calls per day, a hosted paid plan plus disciplined caching covers it. If it lands in the millions, compare a specialized indexing pipeline against running your own node — and weigh the node's five-figure hardware against the pipeline subscription honestly, including the operational headcount the node implies.
FAQ
Is there an archive node concept on Solana like Ethereum's? The role exists but the shape differs. Ordinary Solana nodes retain only recent ledger history locally; deep historical queries rely on infrastructure backed by long-term ledger storage, which providers operate at scale. If your product needs full-history transaction data, verify a provider's actual retention depth for the methods you use — do not assume every endpoint serves genesis-to-now history the way an Ethereum archive node does.
Why do my reads sometimes show a transaction and sometimes not, right after sending? Almost always a commitment-level mismatch: the transaction is confirmed but you are reading at finalized, which lags by design. Pass the same explicit commitment on the send-confirmation and the follow-up reads and the flicker disappears.
Can I run a Solana node on the hardware that runs my Ethereum node? Realistically, no. Anza's RPC guidance — 12+ cores, 256GB+ RAM, multiple high-endurance NVMe drives — is roughly an order of magnitude above a capable Ethereum full-node machine. Repurposing a 32GB box that happily runs Geth or Reth will not produce a usable Solana RPC node.
Do Solana transactions have something like EVM gas estimation over RPC? The API provides simulation (simulateTransaction) and fee queries, and priority fees influence inclusion during congestion. The workflow rhymes with EVM practice — simulate, set fees, send, confirm — but the fee mechanics differ enough that you should implement from Solana's documentation rather than translating your EVM gas code.
Which commitment level should a payments flow use? Read and credit at finalized for the irreversible step, even though it is the slowest, because rollback of a credited deposit is an unacceptable failure. Show pending state to the user at confirmed so the experience stays responsive while the finalized check completes in the background.
How should I budget hosted RPC credits for a Solana app versus an Ethereum one? Assume the same feature costs more calls on Solana, then measure. The multipliers come from structure, not waste: 400ms slots mean any per-block logic fires roughly 30 times as often, history features fan out into one call per signature, and account-state features either scan (expensive per call) or subscribe (many small messages). A prototype week on a free tier with the provider's usage dashboard open tells you your real per-user call profile better than any estimate — size the paid plan from that, not from your Ethereum bill.
Do I need my own node just to get WebSocket subscriptions? No — hosted providers expose WebSocket endpoints alongside HTTP, including on free tiers, and accountSubscribe/programSubscribe work over them normally. Reach for your own node only when your subscription fan-out (thousands of program-wide subscriptions) or scanning volume exceeds what paid hosted tiers permit, which is an indexer-scale problem rather than a dapp-scale one.
Sources
[Solana documentation
[Anza documentation
[QuickNode pricing
[Reth documentation
