The account model changes how you design
Ethereum contracts hold their own state. Solana programs are stateless, and data lives in separate accounts that each transaction must declare up front. That enables parallel execution, since transactions touching different accounts can run together, but it requires careful design of who owns each account and how addresses are derived. Rent, account size limits and reallocation rules also shape schemas, so we decide early what grows, what is fixed and who pays for storage over time.
Program derived addresses give a program deterministic, signer-free accounts. Account size is fixed at creation and rent exemption has a cost, so schemas must be planned. A poorly chosen layout can create a hot account that every user writes to, which throttles throughput and defeats the reason for choosing Solana. Token-2022 extensions can enforce transfer fees or restrict transfers, but wallets and exchanges support them unevenly, which is worth checking before you adopt one.