SQL vs NoSQL
SQL (relational) databases store rows in tables with a fixed schema and strong guarantees. NoSQL is an umbrella for document, key-value, wide-column and graph stores that trade some of those guarantees for flexibility or scale. The question is what your data and consistency needs actually are.
| Dimension | SQL | NoSQL |
|---|---|---|
| Schema | Fixed, enforced | Flexible / schema-on-read |
| Relationships / joins | First-class (JOINs) | Manual or denormalised |
| Transactions | Strong (ACID) | Varies; often eventual |
| Query power | Rich (SQL) | Simpler / engine-specific |
| Horizontal scale | Possible, more work | Often the design goal |
| Examples | PostgreSQL, MySQL, SQLite | MongoDB, DynamoDB, Redis |
Pick SQL when
Anything where correctness, relationships and reporting matter — payments, inventory, systems of record. PostgreSQL with row-level security is my default for real business data.
Pick NoSQL when
High-volume, simple-access patterns (caches, sessions, event logs), flexible/rapidly-changing documents, or extreme write scale where one shape dominates.
Verdict
Start with a relational database (PostgreSQL). Its transactions, joins and constraints prevent whole classes of bugs, and it scales further than people think. Add a NoSQL store for the specific job it is great at — caching (Redis), edge key-value (KV), or a document workload — rather than as your primary source of truth.