Solana's Account Model Is Just a Database. Here's the Schema

Stop Thinking in Smart Contracts

Most Web2 developers learn about blockchains through the lens of Ethereum, where the central concept is the "smart contract" a bundle of code and state deployed at an address. You call the contract, it runs code, and it updates its own storage.

Solana doesn't work this way. And the mental model shift is actually simpler than you'd expect, because Solana's model maps almost perfectly onto something every backend developer already knows: a relational database with strict permission rules.

Let me show you the schema.

The Accounts Table

Imagine a single global table called accounts. Every piece of state on Solana, every wallet, every program, every token balance, and every NFT is a row in this table.

CREATE TABLE accounts (
address VARCHAR PRIMARY KEY, -- the public key, base58 encoded
lamports BIGINT NOT NULL, -- SOL balance in smallest unit
owner VARCHAR NOT NULL, -- which program can write to data
data BYTEA, -- arbitrary state, program-defined
executable BOOLEAN DEFAULT FALSE -- is this a program?
);

That's the entire account model. Every concept you'll encounter in Solana is built on top of this table with these five columns.

Row Types

Different rows in this table serve different purposes, but they all have the same columns.

Wallet accounts executable is false, data is empty, lamports holds the user's SOL balance, and owner is the system program. These are what regular users interact with when they send SOL.

Program accounts executable is true, data contains compiled bytecode, and lamports holds the rent-exempt deposit. These are what you'd call "smart contracts" in Ethereum terminology. The key difference: they hold no mutable state.

Data accounts executable is false, data contains serialized program state, and owner is set to whichever program manages this state. This is where everything interesting lives: token balances, NFT metadata, DeFi positions, and DAO votes.

Sysvar accounts special read-only accounts maintained by the network itself, containing things like the current slot, recent block hashes, and stake history. Think of them as system-managed configuration tables.

The Permission System

Here's where Solana's model gets genuinely clever. The owner column acts as a row-level security rule enforced by the database engine itself except in this case, the "database engine" is the Solana runtime, running on thousands of validators simultaneously.

The rule is simple: only the program whose address matches the owner column can write to that row's data column.

In Postgres terms, it would look something like this:

CREATE POLICY account_write_policy ON accounts
  FOR UPDATE
  USING (owner = current_program_id());

No exceptions. No overrides. The runtime enforces this for every transaction, every time. If your transaction tries to modify an account's data without being the owner, it's rejected before it even runs.

This is radically different from Web2, where your application server has a database connection with credentials that let it write to any table it has access to. On Solana, the permission is encoded in the data itself.

Why Programs Don't Store Their Own State

This is the part that confuses most Ethereum developers: Solana programs (the executable rows in our accounts table) contain no mutable state. Zero. A program account is essentially read-only after deployment.

All mutable state lives in separate data accounts that the program owns. The program is the owner; the data accounts are the rows it's allowed to write.

The database analogy: imagine if your application code literally lived in the database as a stored procedure, but could only modify rows where owner = procedure_name. The code and the data are both in the database, but they're in different rows with different access rules.

Why design it this way?

Upgradability. Because programs hold no state, you can upgrade a program (replace its bytecode) without touching any of the data accounts it manages. In Web2 terms, you can do a zero-downtime deployment that swaps out your application logic without migrating your database.

Parallelism. Because each account is an independent row with a clear owner, the Solana runtime can identify which transactions touch which rows and run non-overlapping transactions in parallel. It's like a database with row-level locking that's smart enough to run concurrent transactions on different rows simultaneously.

Lamports as a Storage Deposit

Every row in the accounts table costs something to store, because validators need to keep all accounts in memory to process transactions efficiently.

Solana handles this with a deposit system called "rent exemption." Each row must hold enough SOL in its lamports column to cover the cost of its storage indefinitely. The formula is roughly proportional to the size of the data column bigger data, bigger deposit.

In Web2 terms: it's like a cloud database that charges you a one-time deposit per row based on how much data that row stores, and refunds the deposit when you delete the row.

When you close a Solana account (delete the row), the lamports are returned to you. This is why Solana programs sometimes "close" accounts that are no longer needed; it's a way to recover the storage deposit.

Reading Is Free, Writing Costs Fees

One more property of this global table that differs from most databases: reads are completely free and permissionless. Anyone can read any row at any time without authentication.

Writes require a transaction, which costs a small fee (typically 0.000005 SOL) regardless of which program is doing the writing. This fee pays the validators for processing the transaction.

So the full permission model is:

• Read any row: free, no authentication required
• Write a row's data: must be the owner program, costs a transaction fee
• Write a row's lamports: the System Program handles SOL transfers, also costs a fee

The One-Sentence Summary

Solana is a globally replicated key-value database where every value has a declared owner program, only the owner can mutate the value, and all state, including executable programs, lives in this same table.

Everything else is an application built on top of that database. Once you have this model, Solana stops feeling foreign and starts feeling like a very well-designed distributed system with unusually strict permission rules.

Which, honestly, it is.