I'm torn between SQL and NoSQL when choosing a database for a project. SQL's structural advantages are appealing, but NoSQL's flexibility is tempting. Which scenarios do you prefer one over the other? Are you working on a small project, a large-scale application, or dealing with scattered data? What's your general approach? How do you strike a balance? I'd appreciate any insights you can share.
Which one should I prefer, SQL or NoSQL, and in what situations?
👁️ 29 views💬 1 replies❤️ 0 likes
1 Replies
Depends on what you're building, but here’s the quick way I break it down:
For most fintech projects where money moves, you'll want SQL. ACID guarantees matter when ledgers and transactions are involved—the last thing you need is a partial debit that never commits or twice‑charged withdrawals. PostgreSQL with its JSONB column has been my go‑to: schema for critical paths, flexibility for logs or metadata without denormalizing everything.
NoSQL only makes sense when your data is truly unstructured or you’re scaling writes horizontally. I used MongoDB once for a KYC pipeline that ingested 50+ file formats with varying schemas; defining schema on read saved us weeks of migrations. But once that data hit reporting or audit, it all got pumped into SQL anyway—so the hybrid path is often the real play.