The Question Is Slightly Wrong
People ask "should I use SQL or NoSQL?" as if it's a binary choice. It isn't. SQL and NoSQL are categories, not products, and within each there are many distinct database types optimized for very different problems. The real question is: what data and access patterns do I have, and which database fits them best?
Most modern systems use multiple databases of different types together. That's normal.
What SQL Actually Means
SQL databases (Postgres, MySQL, Oracle, SQL Server) are relational: data lives in tables with fixed schemas, related to each other through foreign keys. The query language is SQL.
Key properties:
Schema-on-write: the structure is enforced when you insert data.
ACID transactions: reliable, all-or-nothing updates.
Joins: efficient querying across related tables.
Strong consistency: reads always see the latest committed data.
The NoSQL Families
"NoSQL" is an umbrella for many database types. The four main families:
1. Document Stores
Examples: MongoDB, CouchDB, Firestore.
Data model: JSON-like documents. Each document can have different fields.
Best for: hierarchical data (e.g., a blog post with embedded comments), schema-flexible workloads, content management systems.
2. Key-Value Stores
Examples: Redis, DynamoDB, RocksDB.
Data model: a giant hash table. You ask for a key, you get a value.
Best for: caching, sessions, simple lookups. Ridiculously fast at this one thing.
3. Wide-Column Stores
Examples: Cassandra, HBase, ScyllaDB.
Data model: rows, but each row can have different columns. Optimized for writing huge volumes of data and querying by row key.
Best for: time-series, IoT, event logs, anything append-heavy and queried by ID + time range.
4. Graph Databases
Examples: Neo4j, Amazon Neptune, ArangoDB.
Data model: nodes connected by edges, both with properties.
Best for: relationship-heavy data (social networks, recommendation engines, fraud detection, knowledge graphs).
Side-by-Side Comparison
| SQL | Document | Key-Value | Wide-Column | Graph | |
|---|---|---|---|---|---|
| Schema | Fixed | Flexible | None | Flexible | Flexible |
| ACID | Full | Document-level | Limited | Limited | Full (most) |
| Joins | Excellent | Limited | None | None | Excellent |
| Horizontal Scale | Hard | Easy | Easy | Easy | Hard |
| Best Query Pattern | Complex relational queries | Lookup by ID, partial updates | Get by key | Time-series, ID + range | Multi-hop traversal |
The Myth: "SQL Doesn't Scale"
This was true 15 years ago. It is largely false today. Modern Postgres can handle terabytes and tens of thousands of QPS on a single instance. Tools like Citus, Vitess, and Aurora make it scale horizontally too. The "NoSQL because we're at scale" reasoning is mostly outdated.
What's actually true: NoSQL is designed to scale horizontally from day one, while SQL was designed to scale vertically and only later got bolt-on horizontal scaling. If you're starting fresh and you know you'll have millions of users, NoSQL has a smoother path. If you're at any normal scale, SQL is fine and more flexible.
Picking the Right Tool
Use SQL when:
Your data has clear relationships and you'll query them with joins.
ACID transactions matter (money, inventory, anything regulated).
Your access patterns are unpredictable and ad-hoc queries are common.
You don't yet know your scale needs (which is most projects).
Use a Document Store when:
Your data is naturally tree-shaped (a product with variants, a post with comments).
Schemas evolve frequently and you don't want to manage migrations.
You write and read whole objects, not slices of them.
Use a Key-Value store when:
You need extreme speed for simple GET/SET.
Caching, sessions, leaderboards, rate limiters.
Use Wide-Column when:
You write enormous volumes (sensor data, logs, events).
Queries are predictable: "give me data for this user in this time range."
You need to scale to many nodes from the start.
Use Graph when:
Your queries cross many relationships (friends-of-friends, recommended products).
Joins in SQL would be slow because of the depth of traversal.
Polyglot Persistence
Most large products use multiple databases. A typical e-commerce stack might use:
Postgres for orders, customers, inventory (transactional).
Redis for sessions and shopping cart cache.
Elasticsearch for product search.
Cassandra for clickstream events.
Neo4j for the recommendation engine.
This is called polyglot persistence: pick the right database for each problem instead of forcing everything into one.
The One Thing to Remember
SQL vs NoSQL isn't a war you have to pick a side in. SQL is a great default for transactional, relational data. NoSQL gives you specialized tools for specific problems where SQL would struggle. The skill is recognizing which tool fits each problem and being willing to use more than one in the same system.