DEV Community

Cover image for SQL vs NoSQL — A Decision Framework That Actually Works
Dhawal Kumar Singh
Dhawal Kumar Singh

Posted on • Originally published at swehelper.com

SQL vs NoSQL — A Decision Framework That Actually Works

Every developer argues about SQL vs NoSQL. Most of the advice online is surface-level.

Here's a practical decision framework based on how real systems are built 👇

The Core Difference

SQL databases store data in structured tables with predefined schemas. Think rows and columns with relationships enforced by the database itself.

NoSQL databases store data in flexible formats — documents, key-value pairs, wide columns, or graphs. Schema is defined by the application, not the database.

When to Choose SQL

PostgreSQL, MySQL, SQL Server

Pick SQL when you need:

  • ACID transactions — money transfers, order processing, inventory management
  • Complex queries — multi-table JOINs, aggregations, reporting
  • Data integrity — foreign keys, constraints, cascading deletes
  • Mature tooling — ORMs, migration tools, monitoring

Real examples:

  • Stripe uses PostgreSQL for payment processing
  • GitHub uses MySQL for repository metadata
  • Shopify uses MySQL for order management

When to Choose NoSQL

MongoDB, Cassandra, DynamoDB, Redis

Pick NoSQL when you need:

  • Flexible schemas — user profiles with varying fields, product catalogs
  • Horizontal scaling — write throughput across geographic regions
  • High availability — systems that can never go down
  • Specific access patterns — key-value lookups, time-series data

Real examples:

  • Netflix uses Cassandra for streaming metadata (high availability, global scale)
  • Uber uses Cassandra for real-time GPS tracking (massive write throughput)
  • Discord uses Cassandra for message storage (billions of messages)

The 4-Question Decision Framework

When designing a system, ask:

1. Do I need transactions across multiple entities?
→ Yes? Start with SQL. Multi-document transactions in NoSQL exist but add complexity.

2. Will my schema evolve frequently?
→ Yes? NoSQL handles schema changes gracefully. SQL migrations can be painful at scale.

3. Do I need to scale writes globally?
→ Yes? NoSQL databases like Cassandra and DynamoDB are built for this. SQL write-scaling requires sharding, which is hard.

4. Do I need complex aggregation queries?
→ Yes? SQL is purpose-built for this. NoSQL requires you to pre-compute or use separate analytics tools.

What Senior Engineers Actually Do: Polyglot Persistence

Most production systems use both:

Company SQL (Transactions) NoSQL (Scale)
Uber MySQL (trips, billing) Cassandra (GPS, real-time)
Netflix PostgreSQL (billing) Cassandra + DynamoDB (content)
Airbnb MySQL (bookings) Redis (caching) + Elasticsearch (search)

The answer isn't "SQL or NoSQL." It's "which one, where."

CAP Theorem Connection

Your database choice is fundamentally tied to the CAP theorem:

  • SQL databases tend to be CP — they prioritize consistency, may become unavailable during partitions
  • NoSQL databases tend to be AP — they prioritize availability, may serve slightly stale data

Understanding this trade-off is what separates junior from senior engineers in system design interviews.

Wrapping Up

  • SQL for transactions, integrity, and complex queries
  • NoSQL for scale, flexibility, and availability
  • Most real systems use both (polyglot persistence)
  • The right answer depends on your access patterns, not the technology trend

📚 Full guide with comparison tables: swehelper.com/blog/sql-vs-nosql
🔧 Free dev tools (120+): swehelper.com

Top comments (0)