DEV Community: Russell Oje

Solana Accounts vs Web2 Databases

Russell Oje — Fri, 01 May 2026 09:43:27 +0000

"Unlike when you are used to building full-stack applications; a Next.js frontend, connected to a Laravel backend, and modeling state in MySQL or PostgreSQL; moving to Solana requires rewiring how you think about data."

I've been exploring blockchain development with Solana, and the biggest hurdle initially is the phrase: "Everything is an account."

solana account $(solana address)

The output of the CLI command above maps out exactly how traditional Web2 database concepts translate to the Solana runtime.

Here is the side-by-side comparison I put together:

The Web2 vs. Solana comparison table

Concept	Web2	Solana
Data Storage	MySQL/PostgreSQL rows or MongoDB docs	A "flat" byte array in an Account
Logic vs. State	Your Laravel/Node code is the logic; the DB is the state	Both are Accounts; logic is just an account with `executable: true`
Primary Keys	Auto-increment IDs or UUIDs (e.g., `user_id: 101`)	Base58 Public Keys (32 bytes) or PDAs
Security/Auth	Middleware checks (e.g., `$request->user()`)	The Runtime checks: only the "Owner" program can write
Filtering/Joins	`SELECT * FROM table WHERE...` (Server-side)	No Joins. You fetch the account by address or filter off-chain via RPC
Infrastructure	AWS/DigitalOcean monthly bills	"Rent": A lamport deposit you get back when you `close()` the account
Deployment	CI/CD pushes code to a server	Deploying a Program creates an account owned by the BPF Loader

The Biggest Takeaway

In a traditional setup, you deploy your code to a server, and that code orchestrates database transactions. On Solana, both your application logic (programs) and your user data live as accounts in the exact same global space.

There are no native queries, no joins, and no backend middleware guarding your tables. You pay upfront for the bytes you store via rent, and the runtime itself physically blocks unauthorized writes. Your database instincts around data modeling still matter, but the architectural execution is completely flipped.

#100DaysOfSolana

Week1 Recap of #100DaysOfSolana

Russell Oje — Mon, 27 Apr 2026 09:49:04 +0000

This week I generated my first Solana keypair, persisted it, and connected a browser wallet to read my devnet balance in a small app. What surprised me most was realizing my identity is not a username in someone’s database; it is a keypair I control.

Next I hope to turn this into real on-chain interactions and ship something people can use.

#100DaysOfSolana

Week1 of #100DaysOfSolana

Russell Oje — Mon, 27 Apr 2026 09:37:29 +0000

On Day 1 of this challenge, I thought I was doing something small: generate a wallet, print an address, move on.

I ran a script, got a fresh keypair, and saw a long string appear in my terminal. It looked random and slightly intimidating, but also familiar in the same way SSH keys feel familiar. In Web2, I have dozens of identities: GitHub username, work email, banking login, social accounts. Every system has its own account model, its own password reset flow, and its own lockout rules.

Solana felt different immediately. That one keypair was not just an account for one app. It was the beginning of identity across an entire network.

## The Week 1 Journey

### Day 1: "Here is your wallet"

The first script generated a keypair and printed the public key. The idea seemed simple:

Public key = safe to share
Private key = proof of ownership

At this stage, it still felt like setup boilerplate.

### Day 2: "Make it persistent"

Then I built a script that loads an existing wallet from wallet.json or creates one if missing. That changed the feeling.

In Web2, identity is often a row in a database controlled by a platform. In this script, identity became something I could hold, persist, and re-use without asking anyone for permission. I also started to understand responsibility: if I lose this private key, there is no "Forgot Password" link.

### Day 3: SOL vs lamports

I set up the CLI wallet and looked at balances both in SOL and in lamports. One SOL equals one billion lamports. Seeing balances in the smallest unit made Solana feel less abstract. It reminded me of cents in payments systems, except enforced by protocol rules instead of application code conventions.

### Day 4: Browser wallet connection

This was the turning point. I built a Vite page, discovered installed wallets with Wallet Standard, connected Phantom, and fetched balance from RPC.

In Web2 terms, this is what stood out: the app did not "create" my identity. The wallet presented an account, and the app read state from the network. The identity lived outside the app. If I switch apps, I keep the same on-chain identity because it is tied to my keypair, not that product's user table.

### Day 5: Compare wallet types

After trying CLI, browser, and mobile wallets, I saw a practical tradeoff:

CLI: Fastest for scripts; least secure (plaintext file).

Browser: Best for dApps; medium security (password/encryption).
Mobile: Best for personal use; highest hot-wallet security (biometrics).

Different interfaces, same underlying identity model.