SQL vs NoSQL — when each shines

**SQL databases** (Postgres, MySQL, SQL Server): tables with strict schema, relations, JOINs, ACID transactions. Perfect for: business data (customers, orders, invoices), anything with foreign keys, anywhere consistency matters.

NoSQL is an umbrella for several models: document (MongoDB, Firestore — JSON docs), key-value (Redis, DynamoDB — get by key, very fast), wide-column (Cassandra, Bigtable — sparse 2D rows, massive scale), graph (Neo4j — nodes + edges, relationship queries). Each solves a specific shape of problem.

When to pick SQL: when you need ACID (financial, booking), when you need queries you don't know yet (analytics), when your data has clear relations, when 'source of truth' is the concern. ~80% of apps should start here.

**When to pick NoSQL**: very high write throughput (Cassandra — millions of writes/sec), horizontal scale by default without operator pain (DynamoDB), schema that legitimately varies per-record (user-generated JSON), specific query patterns (graph traversal in Neo4j).

Common mistake: picking NoSQL for 'schema flexibility' then reimplementing joins in application code. If you need joins, use SQL. Postgres now has JSONB — you can mix rigid columns and flexible JSON in one engine.

**Polyglot persistence** is the modern pattern: Postgres for business data, Redis for sessions/cache, Elasticsearch for full-text search, ClickHouse for analytics. Use the right tool per concern; don't try to make one DB do everything.