Solana’s blistering speed and sub‑second finality have powered an explosion of memecoins, DeFi, DePIN, and other innovative applications. This network activity generates a constant stream of data that needs to be processed, stored, and served. The responsibility falls to the network’s full nodes.
This blog post explains what a Solana full node is, when it makes sense to run one, and the hardware requirements to consider. We’ll also cover how to set the RPC server and the benefits (and trade‑offs) of self‑hosting.
Whether you're building on Solana or just curious about the infrastructure that keeps it fast, this guide is your on-ramp.
What is a Solana full node
A Solana full node is a server, hosted in the cloud or on hardware, that runs the Solana validator software. It keeps a copy of the blockchain ledger, connects to other participants in the network, and participates in transaction validation.
Source: Solana Validators
The official Solana documentation doesn't explicitly use the "full node" term or perceive it in the same way as some other blockchain ecosystems. Ethereum, for instance, organizes nodes based on how much data they store, hence archive/full/light node distinctions.
Solana categorizes nodes by:
- Whether they help produce and validate blocks (validators);
- or just serve data, responding to dApps and users (RPC nodes).
Both are technically “full nodes” as they have access to or can reconstruct the full state of the ledger.
Role of full nodes in the Solana network
Every Solana node, whether it's a validator or an RPC server, performs the following functions:
- Listens to new blocks as they are produced;
- Verifies all the transactions in those blocks;
- Updates its internal record of the state.
In other words, they all watch and verify every block so they always know the current, accurate state of the blockchain.
This is crucial because all nodes must agree on the state to stay in sync and be the basis for trust in the network. Even non-voting RPC nodes must verify every state change to answer user queries like “What’s the balance of this account?” or “Did this transaction go through?”
Solana validator vs. RPC nodes
Voting is an extra capability that only full nodes running as validators have. It’s this feature that sets them apart from RPC‑only nodes.
Validator nodes on Solana actively participate in the consensus process, have a voting account, and cast votes on the inclusion of blocks in the network.
RPC nodes expose JSON‑RPC methods (getBalance, sendTransaction, getProgramAccounts, etc.) to help read real-time blockchain data, serve historical queries, and deliver transactions to validators for processing.
In practice, both run the same validator software, which is configured differently depending on their purpose.
Below is a quick comparison table of how Solana Validator and RPC nodes’ functions contrast:
| Node Type | Role in Solana Network | Key Responsibilities | Participates in Consensus |
|---|---|---|---|
| RPC Node | API gateway for users & dApps, a reliable source of data | • Answer client queries (e.g., balances, account state) • Accept & forward signed transactions |
No |
| Validator | Block producer and verifier | • Receive and process transactions from RPC nodes • Produce new blocks • Validate & vote on blocks |
Yes |
Here’s how a typical Solana transaction flows through both types of nodes:
- A user interacts with a dApp (e.g., to mint an NFT, send SOL, or stake tokens).
- After building a transaction, the dApp invokes sendTransaction RPC call to relay it to an RPC node.
- The RPC node delivers it to the next leader, a block-producing validator, to be processed.
- The validator packages it into its next proposed block.
- Other validators vote on the block.
- After confirmation, the app or wallet can query the RPC node again to fetch the updated state.
Source: Solana
This separation of roles is important to know because the two types of nodes have different workloads and, as a result, require different machine specs, network setups, and resources.
Solana full node size
Solana produces hundreds of thousands of blocks and millions of transactions every day. If every node kept all of that history, disk usage would exceed the multi‑terabyte range, and hardware requirements would grow indefinitely. To avoid this, Solana’s software will retain only recent ledger data and purge the older entries by default.
In the following sections, we’ll translate these factors into concrete disk, RAM, and hardware recommendations for anyone willing to run a Solana node.
How big is a Solana full node? Disk and RAM requirements
As of April 2025, an unpruned Solana ledger is on the order of 400 terabytes on disk. What most nodes actually store, however, depends on the server settings.
Below are rough ballparks storage recommendations for a full RPC node, based on community reports and official documentations:
- On‑disk ledger (with pruning settings): 1 TB;
- The Accounts Database (the live state of every account): 500 GB;
- Snapshots (recent state checkpoints): 250 GB;
- OS / Logs (optional): 500 GB.
In total, a full Solana node requires at least 2 TB of raw disk space. Additionally, 512+ GB of RAM is recommended to serve data as fast as possible.
RPC servers with archive node settings must provision the full ~400 TB plus overhead for snapshots and RocksDB state (another 100–300 TB depending on indexing flags).
Note: It’s also recommended to have 2 separate NVMEs (storage drives inside the server) to separate the accounts and the ledger, or 4 separate NVMEs to maximize read/write operations.
How Solana’s ledger growth affects node size
Solana is adding 80-95 TB of data per year at today’s traffic levels. This includes on‑chain ledger entries (the raw block and transaction data streamed to disk), not the full state footprint. With state and indexes, the growth is estimated at tens to hundreds of TB more.
Some additional considerations:
- If network usage ramps toward full design capacity (~1 GB/s), the raw block data is estimated to grow at several petabytes/year.
- In most cases, however, pruning defaults keep a disk needs around 2 TB, unless they need to serve deeper history.
- Some operators need archival data access. These nodes must plan for both ledger growth and state/index storage.
Solana’s ledger can outpace modest storage setups pretty quickly. For consistent performance, node operators should continuously monitor disk utilization and factor in increases in network throughput.
Solana full node requirements: hardware and network
In terms of hardware, Solana is extremely demanding. Because RPC nodes handle all validator duties and run a full JSON‑RPC API, they need significantly more powerful hardware compared to a validator setup. The specs list below shows general starting points:
- RAM: ≥ 512 GB (ECC‑capable) or 1TB to support all the indexes;
- Fast modern CPU: 24 cores / 48 threads (AMD strongly preferred);
- GPU: not recommended;
- Network: ≥ 1 Gbit/s symmetric (10 Gbit/s preferred).
For production-grade use cases, running a Solana node on a bare metal server in a professional data center is the most reliable and high-performance setup.
Recommended CPU profiles for Solana nodes (Agave client) / Source: The Solana Hardware Compatibility List
The node operators are advised to run their own benchmarks and adjust CPU, RAM, disk, or networking based on how their specific setup behaves under load.
Self-hosting a Solana full node: What you need to know
When people come from an EVM background and look for a “full Solana node,” they usually need a node that has access to the full blockchain state and can serve RPC requests. So in our guide, we’ll focus on RPC node setup specifically.
We’ll walk through a minimal setup, weigh the benefits and trade-offs of self‑hosting, and explore more accessible alternatives.
Quick guide to Solana node setup and maintenance
The Solana ecosystem has multiple client software instances, including Agave, Jito, and Firedancer. If you’re planning to run a Solana server today, Agave, developed by Anza, is the production‑ready client that many have adopted as their primary software.
Here is a quick walkthrough of the core install and configurations for a Solana RPC node in a Linux environment:
- Install the Solana CLI locally:
sh -c "$(curl -sSfL https://release.anza.xyz/v2.2.6/install)"
- Create and secure data directories:
sudo mkdir -p /mnt/ledger /mnt/accounts sudo chown $USER:$USER /mnt/ledger /mnt/accounts
Optional: format and mount the drives for NVME
- Configure your start script.
A snippet of shell script (validator.sh) with all the flags and parameters you’d need to launch the node properly:
#!/bin/bash exec agave-validator \ --ledger /mnt/ledger \ --accounts /mnt/accounts \ --rpc-port 8899 \ --rpc-bind-address 0.0.0.0 \ --full-rpc-api \ --no-voting \ --known-validator\ --entrypoint entrypoint.mainnet.solana.com:8001\
This script passes the --no-voting and --full-rpc-api flags to enable all RPC operations on the server. It won’t vote or produce blocks itself.
For more detailed guidance, consult the official Anza documentation.
Once your RPC node is live, you’ll want to keep it up‑to‑date:
- Keep Agave current to pick up performance improvements and security fixes.
- Your ledger and accounts folders can grow large. Use the --limit-ledger-size (size in slots) flag to prune beyond that.
- Have a runbook for restarting and resyncing.
- Use separate disks for each major data role (ledger, accounts, snapshots, OS) to maximize throughput and minimize latency.
Following these basic guidelines will help keep your node healthy, responsive, and in sync with the network.
When to run your Solana node vs. using third-party RPC services
Self‑hosting an RPC server gives full control over configurations, tuning parameters, and software versions. However, operating a production‑grade Solana node is non‑trivial. Choosing self-hosting is common in teams and companies with qualified staff to manage the deployment.
In other cases, consider DIY deployment only if you’re comfortable with:
- Longer setup time (provisioning and deployment can take days);
- Hardware expenses and storage growth management;
- Solana’s configuration details;
- Linux / DevOps fundamentals;
- Infrastructure tooling (containerization, orchestration, etc.);
- Ongoing maintenance (updates, security patches, monitoring, backups, and failover);
- Adding multiple servers to scale.
For most developers and teams, a premium RPC provider like GetBlock offers a faster, more reliable path to production:
- Zero infrastructure overhead;
- 99%+ uptime backed by a 24/7 ops team;
- Global, low‑latency endpoints in multiple regions;
- On‑demand access to archival nodes;
- Access to 50+ blockchains for multi‑chain needs;
- Start for free with 50k CUs/day and scale via predictable tiered plans or enterprise agreements.
Larger teams may especially benefit from Dedicated node solutions with self-hosted levels of performance and customization. This includes MEV‑centric functionality of a Jito-client, gRPC plugin, DAS API integration, and more add-ons.
Ready to skip infrastructure headaches? Set up your Solana RPC endpoints, swap months of NodeOps toil for a few lines of code, and go from zero to production‑grade in minutes.
