Solana’s Account Types Are Just Database Rows With Different Flags
The Surprise of Day 25
When I got to Day 25 of 100 Days of Solana and inspected the System Program account for the first time, I expected something special. Some distinct “program” structure, different from the wallet accounts I’d been working with.
Instead I got the same four fields I’d already seen a hundred times: balance, owner, executable, data. The only difference was executable: true.
That was the moment “everything is an account” stopped being a tagline and became something I actually understood. This post explains what I found and what it means if you’re coming from a Web2 background.
The Web2 Mental Model You Need to Drop
In Web2, different things have different types. A user account is a database row. Application code is a file on a server. Configuration data is an environment variable or a config service. They’re stored differently, accessed differently, and reasoned about differently.
Solana collapses all of this into one primitive. Everything your wallet, the code that processes transfers, the network’s current timestamp is a row in the same global table with the same four columns.
The Schema
CREATE TABLE accounts (
address VARCHAR PRIMARY KEY,
lamports BIGINT, -- SOL balance
owner VARCHAR, -- which program controls this row
data BYTEA, -- arbitrary payload
executable BOOLEAN -- is this row code or data?
);
That’s it. Every account on Solana billions of them fits this schema. What varies is the values.
Row Type 1: Your Wallet
address: YOUR_WALLET_ADDRESS
lamports: 1,247,000,000 (1.247 SOL)
owner: 11111111111111111111111111111111 (System Program)
data: empty
executable: false
Your wallet is the simplest possible row. No data payload, not executable, owned by the system program. The SOL balance is all that matters, and it lives in lamports.
Web2 equivalent: A user record with just a balance field. No special logic is attached. The application server (system program) handles all operations on it.
Row Type 2: The System Program
address: 11111111111111111111111111111111
lamports: 1,000,000,000 (1 SOL)
owner: NativeLoader
data: 14 bytes
executable: true
Same schema, completely different purpose. executable: true means the runtime treats the data field as code to execute, not state to store. When you call the System Program, the runtime looks up this row and runs its bytecode.
Web2 equivalent: A stored procedure in your database. It lives in the same storage system as your data rows, but the database engine knows to execute it rather than return it as data.
Row Type 3: Sysvar Accounts
address: SysvarC1ock11111111111111111111111111111111
lamports: 1,169,280
owner: Sysvar1111111111111111111111111111111111111
data: 40 bytes (current slot, epoch, timestamp)
executable: false
Sysvar accounts are read-only rows that the network itself writes to every slot. Programs read them to access runtime information: what slot is it? What’s the current rent rate? What are the recent block hashes?
Web2 equivalent: A system configuration table that your application server updates automatically like a system_config table with current_time, maintenance_mode, and version columns. Your application code reads it but doesn’t write it.
The Flag That Changes Everything
The entire distinction between “code” and “data” in Solana comes down to one boolean: executable.
In Web2, code and data are fundamentally different things stored in different places one on your filesystem, one in your database. You never confuse them. In Solana, they’re the same thing stored the same way. The flag is the only boundary.
This has a profound implication: programs are inspectable the same way data is. You can look up any program’s account in a block explorer, see its bytecode, check its upgrade authority, read its transaction history. There’s no separation between “application layer” and “data layer” it’s all one public table.
What Sat Underneath Everything I Built
Looking back at 25 days of challenges through this lens:
Every airdrop I received → System Program created or credited my wallet row.
Every SOL transfer I sent → System Program debited my row and credited the recipient’s.
Every account I created for a new keypair → System Program inserted a new row.
Every script that read account data → fetched rows from this global table.
The System Program has been the invisible application server behind every operation. Day 25 was the first time I looked at it directly as an account and saw that it’s just another row, with executable: true and the NativeLoader as its owner.
Same table. Same schema. Different flags.
