Introduction
Cloud providers offer both relational (SQL) and non-relational (NoSQL) database services, and choosing between them is one of the most consequential early decisions in application design. The choice affects how your data is structured, how it scales, and what consistency guarantees your application can rely on.
Cricket analogy: Choosing between SQL and NoSQL is like choosing between a Test match squad built for structured, disciplined long-form cricket and a T20 franchise squad built for fast, flexible scoring, an early decision that shapes how the whole team's data, meaning strategy, is structured and how it scales.
Explanation
Relational databases enforce a fixed schema: tables have defined columns and types, and relationships between tables are expressed through foreign keys and queried using joins. They provide ACID guarantees (Atomicity, Consistency, Isolation, Durability), making them well suited to workloads that need strong transactional correctness, such as financial ledgers. Relational databases traditionally scale vertically (bigger machine) more easily than horizontally, though modern distributed SQL systems are narrowing that gap. NoSQL databases relax the fixed-schema requirement and often favor horizontal scaling (adding more nodes) over vertical scaling, frequently trading strict consistency for eventual consistency and higher availability under partition. NoSQL is not one thing; it spans several distinct sub-types: document databases store semi-structured JSON-like documents (e.g., MongoDB, Amazon DocumentDB); key-value stores map simple keys to values for very low-latency lookups (e.g., Redis, Amazon DynamoDB in its simplest use); wide-column stores organize data into flexible column families across rows, well-suited to large-scale write-heavy workloads (e.g., Apache Cassandra, Google Bigtable); and graph databases model entities and their relationships explicitly as nodes and edges, optimized for traversal queries (e.g., Neo4j, Amazon Neptune).
Cricket analogy: Relational databases are like Test cricket's rigid scorecard with fixed columns joined by strict rules, giving ACID-level certainty for a betting ledger, while NoSQL is a flexible T20 fan app: document stores hold player profiles, key-value stores give instant live scores, wide-column stores handle ball-by-ball logs, and graph databases map scouting relationships.
Example
Relational (SQL) example query:
SELECT orders.id, customers.name
FROM orders
JOIN customers ON orders.customer_id = customers.id
WHERE orders.status = 'shipped';
Document (NoSQL) example:
{
"_id": "order123",
"customer": { "name": "Alice", "id": "c1" },
"items": ["sku1", "sku2"],
"status": "shipped"
}
Key-value (NoSQL) example:
GET user:1001:session_token -> "abc123..."
Graph (NoSQL) example:
(Alice)-[:FOLLOWS]->(Bob)-[:FOLLOWS]->(Carol)Analysis
The right choice depends on access patterns and consistency needs. If your application requires complex multi-table joins, strict transactional integrity, and a schema that changes infrequently, a relational database is usually the better fit. If your application needs to scale horizontally across many nodes, handle rapidly evolving or semi-structured data, or serve extremely low-latency key lookups at massive scale, a NoSQL option often fits better. It is common in real systems to use both: a relational database for core transactional data and a NoSQL store (such as a key-value cache or document store) for specific high-throughput or flexible-schema use cases. Choosing NoSQL purely for perceived scalability without a matching access pattern is a common and costly mistake.
Cricket analogy: Complex joins like cross-referencing career stats with strict integrity suit a Test-style relational database; scaling to a global fan base checking live scores suits T20-style NoSQL; real systems often use both, and picking NoSQL just because it sounds scalable, without matching the access pattern, is a costly mistake.
Key Takeaways
- SQL databases use a fixed schema, support joins, and provide ACID guarantees.
- NoSQL databases favor flexible schemas and often trade strict consistency for horizontal scalability.
- NoSQL sub-types include document, key-value, wide-column, and graph databases, each suited to different access patterns.
- Many real-world systems use both SQL and NoSQL databases together for different parts of the workload.
Practice what you learned
1. What consistency model do relational databases traditionally guarantee?
2. Which NoSQL sub-type is best suited for modeling relationships and performing traversal queries, such as social network connections?
3. Which of the following is a key-value store example?
4. What is a common tradeoff NoSQL databases make to achieve horizontal scalability?
Was this page helpful?
You May Also Like
Managed Databases Overview
Learn what a cloud provider handles for you in a managed database service versus running your own database on a VM.
Database Replication and Sharding
Learn the difference between replicating data for availability and sharding data for write scalability.
Microservices in the Cloud
See how managed containers, serverless platforms, service discovery, and API gateways make cloud-native microservices practical to build and operate.
High-Availability Design
Design systems that stay up through redundancy and automatic failover, and understand what each additional 'nine' of uptime really costs.