Solana nodes: validators, RPC nodes, and self-hosting

A wallet reading a balance, an explorer retrieving a two-year-old transaction, and a trading system consuming account updates may appear to use the same Solana service. Underneath, they depend on different infrastructure.

For application teams, the useful question is not simply, “Should we run a Solana node?” It is: Which workloads does our application need, and which parts of the stack should we operate ourselves?

What are the three layers of Solana infrastructure?

When building on Solana, there are 3 types of infrastructure that all stem from Solana nodes. So what is a Solana node? Simply put, a Solana node is a server running validator client software.

Voting validators secure and produce the chain, while non-voting remote procedure call (RPC) nodes expose live state and transaction APIs. Separate archival, indexing, caching, and streaming systems serve workloads that a standard node cannot efficiently retain or answer on its own.

Voting validators secure the chain

Voting validators participate in consensus and help the network agree on the canonical chain. They also produce blocks when selected as leader. Their primary responsibility is staying synchronized, voting correctly, and performing leader duties reliably.

Applications depend on this consensus, but most application requests are not sent directly to voting validators.

RPC nodes serve live application traffic

An RPC node usually runs the same validator client software without voting. It follows the cluster, replays blocks, and maintains current account state, but does not vote or enter the leader schedule.

Instead, it exposes Solana’s RPC interface. Wallets, exchanges, explorers, bots, and other applications use that interface to query chain data, simulate transactions, and submit transactions.

A voting validator can technically expose RPC as well. In production, operators normally keep that interface private or restricted so unpredictable application traffic does not compete with consensus and block production.

Secondary systems serve specialized data workloads

RPC nodes expose Solana’s API, but providers do not have to answer every request directly from a live node. They can use systems built for:

• long-term transaction and block history
• account indexing and expensive filtered queries
• caching frequently requested data
• real-time streams with filtering, buffering, replay, and recovery

For standard RPC methods served by these systems, applications can keep using the same familiar API methods, parameters, filters, and response formats. Only the system answering the request changes. Old history comes from separate storage because the live node no longer has it, while expensive current-state queries can be served more efficiently from dedicated indexes or caches.

Which infrastructure layer handles each Solana workload?

Consider a few common application requests:

• A wallet checks a balance or simulates a transaction. A live RPC node can answer directly from current state.
• An explorer loads a transaction from two years ago. The application still calls a standard RPC method, but the provider answers from archival storage because the live node no longer has the data.
• A portfolio app queries every account owned by a large program. The same RPC method and filters can be served from an account index or cache instead of making a node scan its state repeatedly.
• A trading system needs every account or transaction update as it happens. It uses streaming infrastructure for continuous delivery, often alongside RPC for point-in-time queries.
• A network operator wants to vote and produce blocks. That requires a voting validator, not an application RPC service.

A provider may expose several of these capabilities as one service. The application sees familiar interfaces while different systems handle the work behind them.

How do Solana nodes serve historical data?

Methods such as getTransaction, getBlock, and getSignaturesForAddress can query old activity. A standard RPC node, however, retains only a limited ledger window locally. Once older data has been pruned, adding more CPU does not make the query work. The data is no longer on that node.

Deep Solana archival data requires a separate path that:

1. Ingests blocks and transactions from live and historical sources
2. Detects and repairs missing data
3. Stores the data for long retention and high query volume
4. Serves historical RPC requests from that storage layer

This is why “archive RPC” is not simply a normal node with a larger disk. At production scale, providers typically serve archive RPC from separate storage and query systems, presented through a familiar RPC interface.

At Alchemy, we learned this constraint directly. We initially used Google Bigtable for Solana history, then rebuilt the archival stack on self-hosted HBase. Today, each record is written twice, validated programmatically, and scanned for completeness. When the system finds a gap, it re-ingests the missing entry. Historical methods such as getTransaction and getSignaturesForAddress now read from this optimized data layer rather than relying on the live RPC fleet’s local retention in order to provide the speed and reliability our customers expect.

Why is getProgramAccounts expensive?

getProgramAccounts illustrates a different limitation. The account data exists in current state, but answering the request may require searching a large set of accounts and applying filters at query time.

A node stores accounts primarily so it can replay blocks and maintain current chain state. It is not a general-purpose analytical database. Occasional direct scans may be acceptable, but repeatedly scanning millions of accounts becomes slow and resource-intensive under production traffic.

For sustained workloads, operators can consume account updates continuously and maintain query-friendly indexes or cached views. Requests then read prepared results instead of repeating a full scan each time.

Repeated getProgramAccounts requests are an indexing problem, not a request for a larger node. Phrased another way, the distinction is not “small node versus large node.” It is live node data serving versus indexed data serving.

How do Geyser and gRPC streaming work?

Trading systems, indexers, and other real-time applications often need to process account, transaction, slot, or block updates as they happen.

WebSocket subscriptions are part of Solana’s standard interface and work well for selected live events. For workloads that need lower latency, higher throughput, or richer filtering, Yellowstone gRPC provides a more performant streaming interface built on gRPC over HTTP/2.

The Agave validator client, including when it runs as a non-voting RPC node, can also run Geyser plugins. Geyser emits account, transaction, slot, and block updates as the node processes the chain. Providers can expose that data through Yellowstone-compatible Solana gRPC, adding filtering, buffering, replay, reliability, and multi-node delivery.

Streaming does not replace RPC. RPC answers a question about state. Streaming tells the application that state changed. Many production systems use both.

When should you self-host Solana infrastructure?

Most application teams should start with a provider. One self-hosted RPC node does not automatically cover all of the use cases you need (providing durable history, indexed queries, globally replicated APIs, or data streams), and doing that reliably is a lot of work.

Self-hosting makes sense when control over your infrastructure improves the product or when policy requirements rule out a managed service. Examples include:

• a validator operator participating in consensus
• a latency-sensitive trading system that needs specific node placement or transaction-routing control
• a service that requires custom Geyser plugins, indexes, or retention policies
• an organization with strict compliance or infrastructure-control requirements
• a large platform whose sustained traffic can justify a dedicated infrastructure team

The test is whether owning the infrastructure creates a measurable advantage that outweighs the hardware, engineering, and on-call work.

What does it take to operate Solana infrastructure?

The current Agave hardware guidance sets a high starting point before production traffic, redundancy, and adjacent data systems are considered.

The hardware is only the floor. Under Solana’s current consensus system, voting validators can also spend up to roughly 1.1 SOL per day on vote transactions. Production RPC services need redundant nodes to avoid a single point of failure. Teams that self-host and require deep history, indexes, or reliable streams must operate those systems too.

How do you run a Solana node?

The setup begins with the role, not the command line.

1. Choose the workload. Decide whether the deployment will vote, serve RPC, or feed a specialized data pipeline.
2. Provision the host. Match current CPU, memory, storage, bandwidth, operating-system, and public-IP requirements to the client and role.
3. Configure the role. An RPC operator runs without voting and selects the required history, account indexes, and retention settings. A validator operator configures its identity and vote account.
4. Protect keys and endpoints. Keep sensitive keys off the validator host. Put public RPC and WebSocket endpoints behind authentication, rate limits, and load balancing.
5. Operate the complete service. Monitor synchronization, disk, CPU, network, process health, and application-level errors. Plan for upgrades, recovery, failover, and abuse.

Use the maintained Agave guides for current validator commands and flags or RPC node setup.

How should you evaluate a Solana infrastructure provider?

Start with the workloads your application needs, then ask how the provider serves each one.

Benchmark the methods, subscriptions, and regions your application will use. The Solana RPC providers guide compares current options across those criteria.

The takeaway

A Solana application does not need “a node” in the abstract. It needs specific capabilities: live state, transaction APIs, history, indexed queries, streams, or, in a much smaller set of cases, consensus participation.

Identify those workloads first. Then decide which parts of the stack provide a real advantage when operated internally and which are better obtained from a managed service.

Build on Solana with Alchemy

Most application teams do not need to operate their own RPC fleet, archival databases, indexes, and streaming infrastructure. We provide live Solana RPC for state and transactions, block and transaction history from genesis over standard methods, and Yellowstone-compatible gRPC for real-time streams.

Start building on Solana, follow the Solana API quickstart, or talk to our team about dedicated capacity and custom workloads.

Frequently asked questions

What is a Solana node?

A Solana node is a server running validator client software. It follows the cluster, replays blocks, maintains current chain state, and communicates with peers. Voting validators participate in consensus and block production. Non-voting RPC nodes expose application APIs.

What is the difference between a validator and an RPC node?

Both follow and replay the chain. A voting validator participates in consensus and may produce blocks when selected as leader. An RPC node does not vote or enter the leader schedule. It focuses on serving live state and transaction APIs to applications.

Is an archive node a separate Solana node type?

Not usually. Deep transaction and block history is generally served by a separate archival data system behind an RPC-compatible interface, not by a standard node with a larger disk.

Do applications need to run a validator?

Usually not. Applications depend on validators to establish the chain, but their own requests normally go to RPC nodes and specialized data services. Running a validator is necessary for consensus participation, not ordinary application access.

What are the hardware requirements for a Solana validator or RPC node?

Current Agave guidance starts at 12 cores, 24 threads, and 256 GB RAM for a voting validator. A non-voting RPC node starts at 16 cores and 32 threads, with 512 GB RAM recommended when running all account indexes. Both require fast NVMe storage and reliable networking.

Do I need SOL to run a Solana node?

A non-voting RPC node does not require SOL for voting. A voting validator needs funded identity and vote accounts and pays vote-transaction costs under the current consensus system.

Is running a Solana validator profitable?

It depends on delegated stake, voting performance, commission, transaction-fee income when selected as leader, maximum extractable value income, and operating costs. Validators with little delegated stake often struggle to break even. Treat validator operation as its own infrastructure business, not as a way to give an application RPC access.

How do you run a Solana node?

Choose the role first, provision against current client requirements, configure voting or RPC behavior, secure keys and endpoints, and add monitoring and failover. Use current Agave documentation for commands and flags because supported releases and recommendations change.

Should I self-host an RPC node or use a provider?

Use a provider when you need managed capacity, historical data, indexed methods, streaming, or failover without operating those systems yourself. Self-host when control, custom configuration, physical placement, sustained scale, or policy requirements justify a dedicated infrastructure team.