Skip to main content

Compare accounts vs databases

Deepen your understanding of how Solana accounts compare to Web2 databases.
Compare accounts vs databases background
View Your Submissions
Challenge

Compare accounts vs databases

The Scenario

You have spent years working with databases. MySQL, PostgreSQL, MongoDB: you know how to model data, write queries, and think in tables or documents. Now you are building on Solana, and someone tells you “everything is an account.” That sounds simple enough, but the mental shift is bigger than it seems. Today you are going to put the two models side by side and make the differences concrete. By the end, you will know exactly where your database instincts still apply and where you need to rewire your thinking.

The Challenge

What You’ll Need

  • A terminal with the Solana CLI installed
  • Your Solana CLI configured to devnet (solana config set --url https://api.devnet.solana.com)
  • A devnet wallet with some SOL (run solana airdrop 2 if needed)
  • A text editor or notes app for your comparison table

Steps

Step 1: Inspect your own wallet account

Every wallet on Solana is an account. Let’s look at yours. Run the following command to get your wallet’s public key:

solana address

Now inspect that account:

solana account $(solana address)

You will see output showing the account’s balance (in lamports), its owner (the System Program at address 11111111111111111111111111111111), the data length (0 bytes for a plain wallet), and whether it is executable (false).

In a traditional database, your user record might live in a users table with columns like id, balance, and email. On Solana, this account is your “row,” but instead of living in a table that a single server controls, it lives on a global ledger that thousands of validators maintain together.

Step 2: Inspect a program account

Now look at something executable. The Token Program manages all SPL tokens on Solana. Inspect it:

solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Notice the differences: the executable field is true, and the owner is the BPF Loader. This account stores compiled program code, not user data. In Web2 terms, this is like the application binary that lives on your server, while your wallet was like a record in a database. On Solana, both code and data live in the same account model, not separate systems.

Step 3: Build your comparison table

Open your text editor and create a comparison table with these categories. Fill in each row based on what you have learned so far and what you already know from your Web2 experience:

Concept Traditional Database Solana Accounts
Data location Rows in tables on a centralized server Accounts on a distributed ledger across validators
Schema Defined by the database (SQL DDL, document schema) Defined by the owning program; stored as raw bytes in the account’s data field
Access control Application-level auth (SQL roles, app middleware) Enforced by the runtime: only the owning program can modify an account, and only with the required signer(s)
Cost of storage Server/cloud hosting fees, pay for disk space Rent-exempt deposit proportional to data size (query via solana rent); refundable when the account is closed
Identity/keys Auto-increment IDs, UUIDs 32-byte public keys or Program Derived Addresses (PDAs)
Reads SQL queries, document lookups RPC calls (getAccountInfo, getProgramAccounts)
Writes INSERT/UPDATE via application code Transactions with instructions, signed by authorized keys
Code vs data Application code and database are separate systems Both are accounts; programs (code) and data accounts coexist in the same model
Deletion DELETE query removes the row Close the account, lamports are returned to you
Visibility Private by default; you choose what to expose Public by default; anyone can read any account’s data

One key difference: accounts do not query each other. There is no JOIN, no server-side filtering. Programs receive accounts as inputs to instructions. If you want to “query” data, you do it off-chain via RPC and assemble results yourself.

Step 4: Check the rent-exempt cost for a data account

In a database, storage costs are part of your hosting bill. On Solana, storage costs are explicit: you deposit lamports proportional to the size of the data you want to store. This deposit is fully refundable when you close the account.

Check how much it costs to store different amounts of data:

solana rent 0
solana rent 100
solana rent 1000

The solana rent command uses the getMinimumBalanceForRentExemption RPC method under the hood. Notice how the cost scales linearly with data size. Compare that to traditional databases where storage cost is abstracted into infrastructure pricing rather than attached directly to each record.

Step 5: View an account on the explorer

Open Solana Explorer in your browser and paste in your wallet address. You will see the same information the CLI showed you, but in a visual interface. Click around, look at the transaction history, and notice how every interaction is a transaction that modifies account state.

Now imagine doing the same with a traditional database. You would need admin access, a database client, and permission from whoever runs the server. On Solana, every account is publicly readable by anyone, anywhere, at any time. That is a fundamental difference in how data transparency works.

Run It

solana config set --url https://api.devnet.solana.com
solana airdrop 2
solana account $(solana address)
solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
solana rent 0
solana rent 100
solana rent 1000

> Note: The devnet airdrop can sometimes fail due to rate limiting. If this happens, try a smaller amount (solana airdrop 1) or use the web faucet instead.

What Just Happened

You just took two systems you interact with every day (a database and a blockchain) and put them under the same lens. The core insight is that Solana’s account model is not trying to replace your database. It is solving a different problem: storing state in a system where no single entity has control, where every read is public, and where every write must be cryptographically authorized.

Your database instincts are still valuable. Thinking about schemas, data modeling, and efficient reads all carry over. But the constraints are different. On Solana, you pay per byte stored (not per query), access control is enforced by the runtime (not your application code), and transparency is the default (not something you opt into). Recognizing where the analogy holds and where it breaks is what separates a developer who can use Solana from one who truly understands it.

The comparison table you built is a reference you can keep coming back to as you go deeper into Solana development. Every time you catch yourself thinking “I would just add a column for that,” pause and ask: “How does this map to an account?”

Resources

Submission

Take a screenshot showing the output of solana account $(solana address) alongside your completed comparison table. Share it on social media with the hashtag #100DaysOfSolana.

Submit your project