SQL vs NoSQL
Real Incident: MongoDB + E-commerce, 2014
A startup stored orders in MongoDB. No transactions. A race condition during checkout: payment charged but order not saved. $47,000 lost in a weekend. They migrated back to PostgreSQL. "Schemaless" means the schema is now YOUR problem.
The 30-Second Explanation
There is no "best" database. There's only the right tool for the data shape, access patterns, and scale requirements.
SQL (Relational)
Structured data, ACID transactions, complex queries, strong consistency
PostgreSQL, MySQL, Spanner
NoSQL
Flexible schema, horizontal scale, high throughput, eventual consistency
DynamoDB, Cassandra, MongoDB
Decision Framework (What FAANG Interviewers Want)
| If your data has... | Choose | Because |
|---|---|---|
| Relationships (joins needed) | SQL | NoSQL joins = application-level nightmare |
| ACID transactions needed | SQL | Money, inventory, bookings |
| Fixed schema, complex queries | SQL | SQL query planner >> manual indexing |
| High write throughput (100K+ wps) | NoSQL | Horizontal scaling without sharding pain |
| Flexible/evolving schema | NoSQL | No migrations, schema-per-document |
| Massive scale, simple access patterns | NoSQL | Designed for partition + replication |
| Time-series / event data | NoSQL (or specialized) | Append-heavy, range queries by time |
| Graph relationships | Graph DB (Neo4j) | Traversal is O(1) per hop vs O(n) joins |
NoSQL Types
| Type | Data Model | Best For | Example |
|---|---|---|---|
| Key-Value | Simple key → value | Caching, sessions, config | Redis, DynamoDB |
| Document | JSON-like documents | Content, catalogs, user profiles | MongoDB, CouchDB |
| Wide-Column | Row key → column families | Time-series, IoT, analytics | Cassandra, HBase |
| Graph | Nodes + edges | Social networks, recommendations | Neo4j, Neptune |
The Real Comparison
| Aspect | SQL | NoSQL |
|---|---|---|
| Schema | Rigid (enforced) | Flexible (schema-on-read) |
| Scaling | Vertical (bigger machine) or hard sharding | Horizontal (add nodes) |
| Transactions | Full ACID | Limited or none (varies) |
| Consistency | Strong (default) | Eventual (configurable) |
| Joins | Native, optimized | Application-level or denormalize |
| Query language | SQL (universal) | Varies by system |
What FAANG Actually Uses (Both!)
| Company | SQL For | NoSQL For |
|---|---|---|
| Spanner (global ACID) | Bigtable (analytics, search index) | |
| Amazon | Aurora (orders, payments) | DynamoDB (cart, sessions, catalog) |
| Netflix | PostgreSQL (billing) | Cassandra (viewing history, 100M+ users) |
| Uber | PostgreSQL (trips, payments) | Custom (Schemaless) for high-write |
| Meta | MySQL (user data, social graph) | TAO cache + HBase (messages, analytics) |
Key insight for interviews: The answer is almost always "use BOTH." SQL for transactional core, NoSQL for high-throughput read/write paths.
ACID vs BASE
| ACID (SQL) | BASE (NoSQL) | |
|---|---|---|
| A | Atomicity | Basically Available |
| C | Consistency | Soft state |
| I | Isolation | Eventually consistent |
| D | Durability | — |
| Guarantee | All or nothing, always correct | Available even if slightly stale |
| Best for | Money, inventory, bookings | Feeds, analytics, sessions |
Scaling Strategies
| Strategy | SQL | NoSQL |
|---|---|---|
| Read replicas | Master → N replicas | Built into most (Cassandra, DynamoDB) |
| Sharding | Hard (application-level routing) | Native (auto-partitioned) |
| Caching | Redis/Memcached in front | Sometimes built-in (DynamoDB DAX) |
| Denormalization | Painful (breaks normal forms) | Natural (store data as you query it) |
The 3 Mistakes That Get You Rejected
Don't Say These
- "NoSQL is always faster" — PostgreSQL with proper indexing beats unindexed MongoDB every time. Speed depends on data model + access pattern, not the label.
- "SQL can't scale" — Google Spanner is SQL and spans the globe. Amazon Aurora handles millions of transactions/sec. The scaling ceiling is very high.
- "Use MongoDB for everything because it's flexible" — Flexible schema = schema bugs in production. When you need joins, transactions, or complex queries, you'll regret it.
Interview Answer Template
"For [system], I'd use [SQL] for [transactional data: orders, payments, user accounts] because [ACID, joins, consistency]. For [high-throughput data: activity feeds, sessions, events], I'd use [NoSQL: DynamoDB/Cassandra] because [horizontal scale, flexible schema, write throughput]. The key is not SQL vs NoSQL — it's using each where its strengths match the access pattern."
Quick Recall Card
| Question | Answer |
|---|---|
| When SQL? | Relationships, transactions, complex queries, strong consistency |
| When NoSQL? | Scale, flexible schema, simple access patterns, high throughput |
| Can SQL scale? | Yes (read replicas, Spanner, Aurora). Just harder to shard. |
| Does NoSQL have transactions? | Some do (MongoDB 4.0+, DynamoDB). But limited compared to SQL. |
| Most common pattern? | SQL for core + NoSQL for scale-out paths |
| ACID vs BASE? | ACID = correctness first. BASE = availability first. |