Where does data on Solana actually live?
Mint an NFT, deploy a program, post on a Solana social app, and then ask a simple question: where are the bytes? The answer surprises most people. Solana itself stores astonishingly little, charges a fortune for it, and almost everything you think is "on-chain" actually lives somewhere else.
How Solana stores data natively: accounts and rent
Everything on Solana lives in accounts: your wallet balance, a token's supply, a program's code, an NFT's ownership record. An account is a small container of bytes (up to 10 MiB) that every validator keeps in fast storage, because any transaction might touch it at any moment.
That replication is what makes Solana fast, and it is also why on-chain bytes are premium real estate. To create an account you must deposit enough SOL to make it rent-exempt: roughly 3,480 lamports per byte-year, charged as a two-year deposit up front. The deposit comes back when you close the account, but while your data exists, the SOL is locked:
At typical SOL prices, a megabyte on-chain ties up hundreds of dollars. Cloud storage charges about $0.023 per gigabyte-month (S3 standard). That gap, several orders of magnitude, is not a bug. It reflects what you are buying: bytes that 1,000+ validators replicate and any program can read mid-transaction.
So where do the actual files go?
Since nobody sane puts a JPEG in an account, the ecosystem evolved a standard pattern: keep a pointer on-chain, keep the payload off-chain. Your NFT is really an on-chain record that says "the metadata is at this URI." The metadata JSON then points to the image. Both usually live on one of these:
Arweave: pay once, store forever
A permanent-storage network where a one-time fee funds an endowment intended to pay for replication indefinitely. Metaplex made it the default home for Solana NFT media, and for archives ("this must never disappear") it is the reference choice. The trade-off: you cannot update or delete, and cost scales with size.
IPFS: content addressing, not storage
IPFS gives content a fingerprint (CID) so anyone can verify they got the right bytes. But IPFS itself does not promise anyone keeps the bytes: something must pin the file (your node, a pinning service like Pinata, or Filecoin deals). Unpinned data quietly vanishes. Great addressing layer, commonly misunderstood as a storage guarantee.
Shadow Drive: Solana-native object storage
GenesysGo's storage network, paid in SHDW and built specifically for Solana apps that want fast S3-like storage with on-chain accounting. A pragmatic middle ground used by several Solana projects.
Filecoin: contract-based bulk storage
Storage deals with providers who must keep proving they still hold your data. Strong for large cold datasets; historically weaker on instant retrieval, and it lives outside the Solana execution world entirely.
Plain web servers: the quiet default
A large share of "NFT" media and app data sits on ordinary servers and CDNs behind a URL. It works until the bill stops being paid, the domain lapses, or the project rugs, and then the on-chain pointer points at nothing. Link rot is the silent failure mode of "on-chain" assets.
The comparison, honestly
| Option | Model | Permanence | Can a Solana program read/write it? | Best for |
|---|---|---|---|---|
| Solana accounts | Rent-exempt deposit (~6.96 SOL/MB) | While deposit locked | Yes, natively | Small hot state: balances, ownership, config |
| Arweave | Pay once (endowment) | Designed permanent | No, pointer only | NFT media, archives, provenance |
| IPFS | Free protocol + paid pinning | Only while pinned | No, pointer only | Content addressing, mutable frontends |
| Shadow Drive | Pay in SHDW | While maintained | No, pointer only | Fast app storage in the Solana world |
| Filecoin | Storage deals, renewable | Deal duration | No, different chain | Big cold datasets |
| Centralized (S3/CDN) | Monthly billing | Whoever pays the bill | No | Speed and convenience, accepted fragility |
| Xandeum | Storage layer + wSOL fees | While network stores it | That is the design goal (early stage) | Program-accessible app data (emerging) |
The gap nobody solved yet: storage a program can use
Look down that fourth column. Every off-chain option shares the same limitation: the data is invisible to on-chain logic. A program cannot check an Arweave file's contents inside a transaction, branch on an IPFS document, or update a record on S3. Apps glue it together client-side, which works, but it means the "decentralized" data layer sits outside the trust boundary that makes smart contracts interesting in the first place.
That gap is the specific bet Xandeum is making: a storage layer designed to be read and written from smart contracts (peek and poke primitives, with proofs), blockchain-agnostic by design and integrated first with Solana. We should be clear about its stage, because we monitor it live: the network today has roughly 114 storage nodes and about 355 TB of committed capacity, of which well under 1% is used. The supply side is real and growing; the demand side (apps actually storing paid data) is still early. Live numbers, any time, on our dashboard.
What should you actually use?
- Ownership, balances, small state: Solana accounts. That is what they are for; keep them minimal.
- NFT media and anything that must outlive you: Arweave (often via Irys), with the CID/URI on-chain.
- App content that changes: Shadow Drive or a pinned-IPFS setup, accepting that permanence equals maintenance.
- Large cold archives: Filecoin deals.
- Data your program logic needs to touch: today, you compress it into accounts or restructure the app around pointers; this is the frontier Xandeum targets. Watch usage, not promises: the used-storage number tells you when that future arrives.
FAQ
Where does Solana store data?
In accounts replicated by every validator. That is fast but expensive, so apps keep only small hot state on-chain and put files and archives on external storage (Arweave, IPFS, Shadow Drive, Filecoin, or centralized servers), with an on-chain pointer.
How much does 1 MB on Solana cost?
About 6.96 SOL locked as a refundable rent-exempt deposit (roughly 3,480 lamports per byte-year, two years up front). Hundreds of dollars per megabyte at typical prices, which is why media never goes directly on-chain.
Are NFT images on-chain?
Almost never. The chain holds ownership plus a URI. The JSON and image live off-chain, and if that copy vanishes (unpinned IPFS, dead server), the NFT points at nothing. Arweave-backed media is the sturdier pattern.
What is rent, exactly?
A deposit that compensates validators for replicating your bytes: hold about two years' worth of the rent rate and the account is rent-exempt. Close the account and the SOL comes back.
Can a program read IPFS or Arweave data?
No. Programs only read accounts during execution. External data is fetched client-side, outside the trust boundary. Making storage program-accessible is the open problem layers like Xandeum aim at.
Disclosure: Pulsar Network operates 12 Xandeum pNodes and accepts XAND delegation, so we benefit if Xandeum succeeds. That is why the Xandeum section above states its early stage with live numbers instead of hiding them. Not financial advice.