100 Days of Solana — Week 2 Reflection: How Solana Broke My Web2 Brain (In a Good Way)

#100daysofsolana #solana #web3 #beginners

I want to be honest with you.

When I signed up for the 100 Days of Solana challenge, I thought it was going to be like learning a new JavaScript framework. Same concepts, different syntax. I would pick it up in a few days and move on.

I was wrong.

Two weeks in, and Solana has genuinely changed how I think about databases, storage, and what it even means to "store data." I am still a student. I am still figuring things out. But some things clicked this week in a way that I want to write down before they fade, and maybe help someone else who is starting from the same place I was.

When things started to make sense: Accounts

The biggest mental shift for me was understanding that on Solana, everything is an account.

Coming from Web2, that sentence sounds normal until you realize what it actually means. I was expecting something like a database with tables: one table for users, one for tokens, one for transactions. That is not how it works at all.

On Solana, your wallet is an account. A smart contract is an account. A token is an account. They all use the same underlying structure. The thing that tells them apart is a few fields: whether the account is executable (code or data?) and who the owner is (which program controls it?).

To see this for real, I used the Solana CLI to inspect two accounts side by side:

solana account cRrbhRLCyJcWV6Tmzti4v7aXXXSaRVckTGwaDCspNZM

My wallet came back with:

Owner: 11111111111111111111111111111111 (the System Program, Solana's root engine)
Executable: false
Length: 0 bytes

Just a record tracking a balance. No custom fields. No tables. Then I queried a live smart contract and the properties flipped completely. Executable became true, the owner changed to the BPF Loader, and instead of a balance it returned raw binary data representing compiled program code.

Same account structure. Totally different purpose. That is when the "global public database" idea stopped being a metaphor and became something I actually understood.

Switching environments is just one URL change

In Web2, moving from a staging environment to production is serious work. You update environment variables, run migrations, pray nothing breaks. It is a whole process.

On Solana? You change one URL.

I wrote a script using @solana/kit that queried the same program address on both Devnet and Mainnet at the same time:

import { createSolanaRpc, devnet, mainnet, address } from "@solana/kit";

const devnetRpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));
const mainnetRpc = createSolanaRpc(mainnet("https://api.mainnet-beta.solana.com"));

The output showed the same address holding completely different balances and transaction histories on two separate networks. Same code. Same API calls. But Devnet and Mainnet are isolated ledgers that have never shared state.

This is actually cleaner than most Web2 staging setups I have seen. The logic does not change at all. Only the data source does.

The thing that surprised me most: you pay rent for RAM

This one genuinely caught me off guard.

In cloud computing, you pay for storage on a hard drive. On Solana, validators store all active account data in RAM, because RAM is what makes the network fast. And RAM is expensive. So the network charges a deposit per byte of data you store.

It is called rent, and it is refundable. If you close an account later, you get 100% of that deposit back into your wallet.

I ran these two commands to see the difference:

solana rent 0
solana rent 1000

Watching the lamport cost scale up linearly per byte made storage costs feel very real and very predictable in a way that cloud bills never do. And the fact that you can reclaim it? That is a design pattern I have not seen anywhere in traditional backend development.

What I am taking into Week 3

I will not pretend everything is smooth. There are still moments where I open the terminal and something fails and I have to go read the docs again. That is just part of it.

But I am genuinely curious now in a way I was not two weeks ago. How does Solana maintain atomicity when multiple accounts are being updated in one transaction? How do you structure a transaction to avoid bottlenecks when you have a lot of data to write?

These are questions I could not have even asked on Day 1. The fact that I am asking them now means something is working.

If you are also doing this challenge or thinking about starting, do not wait until you feel ready. The understanding builds as you go. Week 2 Mudi knows things that Week 0 Mudi had no framework to even imagine.

See you on Day 14.

This post is part of my #100DaysOfSolana journey with Major League Hacking. I write about what I learn each week, including the confusing parts.