Day 13 of 100 Days of Solana — Reflecting on Reading On-Chain Data
When I started this challenge two weeks ago with Major League Hacking(MLH), I thought blockchain was just a ledger with transactions. I was wrong—and that realization is worth writing about.
The Expectation vs. Reality
Before I touched any code, I imagined blockchain data like this:
- Transactions sit in a database somewhere
- I'd need special permission to read them
- The data would be siloed, private by default
- Maybe I'd need to run a full node myself
What I actually found:
I could query a random program address on the internet and instantly see its balance, owner, executable flag, and transaction history. No API key. No permission. No credentials. Just:
const account = await connection.getAccountInfo(publicKey);
console.log(account.lamports); // 2,500,000,000
That moment when I ran npm run inspect and saw my account details appear instantly? That was the click.
The Moment It Clicked: "Public By Default"
On Day 11, I created a comparison table between traditional databases and Solana accounts. The row that hit me hardest was:
| Visibility | Database | Solana |
|---|---|---|
| Private by default; you choose what to expose | Public by default; anyone can read any account's data |
In Web2, I'm used to databases being fortresses. You build walls, then decide who gets in. On Solana, every account is an open book the moment it exists. The security model is completely inverted.
This isn't a bug. It's the feature.
When I queried the same address on both devnet and mainnet on Day 12, I saw:
- Devnet: 0.001159846 SOL, recent transactions, fresh account
- Mainnet: 0.069875097 SOL, different transaction history, independent state
Same address. Same blockchain. Different networks. Different data.
It finally made sense: this isn't one database. This is multiple distributed ledgers, all queryable in the same way, all public by design.
The Most Surprising Thing: No JOINs
When I learned that Solana programs can't query each other—that there are no JOINs, no server-side filtering, no SQL—I thought it was a limitation.
It's not.
It's a completely different mental model.
In traditional APIs, I'd hit /users/123/posts and the server would JOIN the users table with the posts table. Solana doesn't work that way. Programs receive accounts as inputs. If I want to "query" related data, I fetch it on the client and assemble it myself.
At first, this felt clunky. Then I realized: this is why Solana is so fast. There's no server deciding how to optimize my query. I get the raw data and compose it however I need.
RPC Calls vs. Traditional APIs
I've worked with REST APIs for years. You know the pattern:
- Make a request
- Wait for the server to think
- Get back JSON
- Hope it has what you need
RPC calls feel different. Faster. Simpler.
const signatures = await connection.getSignaturesForAddress(publicKey, { limit: 5 });
This returns transaction signatures. Not a pretty dashboard. Not a summary. Just the data. The API surface is thin. The results are raw.
It's refreshing. It forces me to think about what I actually need, rather than what the API decided to give me.
The Rent Model: Storage That Costs Real Money
This blew my mind: on Solana, storage costs are explicit and tied to your account.
On Day 11, I built a rent calculator. For a 0-byte account: ~890,880 lamports. For a 1000-byte account: ~1,874,880 lamports. The cost scales linearly with data size.
In Web2, storage is abstracted. You pay a monthly AWS bill, somewhere in a spreadsheet. On Solana, you pay per byte. Every byte is yours to manage.
This is radical. And terrifying. And smart.
It means you think about data efficiency. It means bloat has consequences. It means storage is a feature, not an externality.
What Still Confuses Me
✗ Program Derived Addresses (PDAs) — I see them mentioned constantly but haven't built one yet
✗ Cross-program invocations (CPIs) — How do programs call other programs safely?
✗ The difference between accounts and wallets — I understand the technical difference, but the mental model still feels fuzzy
✗ Rent refunds — When I close an account, the lamports come back... to where?
What Clicked This Week
✅ Accounts are objects. Not records in a table. Not documents in a database. Objects with data, an owner, and permissions.
✅ Public data is the default. Not something you have to enable. Something you have to be intentional about hiding.
✅ Same address ≠ same account across networks. Devnet, testnet, mainnet are completely separate blockchains. Your address looks the same; the state is different.
✅ "Reading on-chain data" is just fetching. No joins. No transactions. No consistency guarantees (beyond finality). Just: "Give me this account's data."
For Next Week
I've spent two weeks reading. Next week, I want to write.
Not transactions. Not messages. I want to write data to the blockchain using my own program. I want to understand what happens when I create an account, store something in it, and then modify it.
I want to feel, in my fingers, what it means that the runtime enforces: "Only your program can modify your data."
The Big Picture
Two weeks ago, I thought blockchain was a ledger. Now I think it's a database—a weird one, by Web2 standards, but a database nonetheless.
The rules are different:
- No schema
- No server
- No private data
- No join operations
- Storage costs are explicit
It feels strange. It feels broken in ways I don't have names for yet.
But it also feels true. And transparent. And distributed.
And that's worth building on.
What surprised you most when you started learning Solana? Drop a comment—I'd love to know.
Catch-up on week 1 write-up here.
Building in public. Learning in public. Days 1-13 of 100.
