Database Sharding Explained
What database sharding is, when you need it, how to choose a shard key, range vs hash vs directory sharding, and the operational pain points to plan for.
SQL vs NoSQL: How to Choose
SQL vs NoSQL explained: data models, consistency, scaling, query flexibility and when to use relational, document, key-value, wide-column or graph databases.
Key takeaways
- Choose relational databases for structured data, joins and strong transactional guarantees.
- Choose NoSQL when your access patterns are simple and predictable and you need massive horizontal scale or flexible schemas.
- Most systems benefit from starting relational and adding specialised stores later.
On this page
“SQL or NoSQL?” is one of the first questions in almost every system design discussion. The honest answer is that it depends on your data and how you query it, not on fashion.
The core difference
SQL (relational) databases store data in tables with a defined schema and relationships between tables. You query them with SQL, including joins, and they typically offer ACID transactions (see ACID and isolation levels).
NoSQL is an umbrella for several non-relational models, each optimised for particular access patterns:
| Type | Model | Good for |
|---|---|---|
| Key-value | Values looked up by key | Caches, sessions, simple lookups |
| Document | JSON-like documents | Flexible, nested records |
| Wide-column | Rows with dynamic columns, partitioned by key | Very large write-heavy workloads |
| Graph | Nodes and edges | Relationships: social graphs, recommendations |
How they compare
| Relational | NoSQL (typical) | |
|---|---|---|
| Schema | Defined up front; migrations to change | Flexible or schema-on-read |
| Queries | Rich: joins, aggregations, ad hoc | Optimised for known access patterns |
| Transactions | Strong, multi-row ACID | Varies: often single-item, some offer more |
| Scaling | Vertical first; horizontal with effort | Designed for horizontal partitioning |
| Consistency | Strong by default | Often tunable or eventual |
When to choose relational
- Your data has clear relationships: users, orders, payments.
- You need transactions across multiple records.
- You need flexible, ad hoc queries and reporting.
- Your scale fits on one powerful primary with read replicas, which covers a huge range of products.
When to choose NoSQL
- You have a simple, predictable access pattern, such as fetching by key.
- You need to spread very high write volumes across many machines.
- Your records vary widely in shape.
- You’re modelling highly connected data (graph).
It’s rarely either/or
Real systems often use several stores: a relational database as the source of truth, a key-value cache for hot reads (see caching strategies), a search index and perhaps a wide-column store for events. The skill is matching each workload to the right tool.
Scaling considerations
Relational databases scale reads with replicas and writes with sharding, which adds complexity. Many NoSQL systems shard automatically using techniques like consistent hashing, trading some query flexibility and consistency for scale; the CAP theorem explains why.
Frequently asked questions
Is NoSQL faster than SQL?
Not inherently. NoSQL can be faster for the specific access patterns it’s designed for; relational databases are very fast when well indexed.
Can relational databases scale horizontally?
Yes, through sharding and distributed SQL systems, though it requires more design effort.
Which should I use for a new startup?
A relational database is usually the safest default: flexible queries and strong guarantees make it easier to evolve your product.
Sources
Every article is edited by a human and checked against our editorial policy. Spotted a mistake? Tell us.
Keep reading
B-Trees vs LSM Trees: How Databases Store Data
How B-tree and LSM-tree storage engines work, why one favours reads and the other writes, write and read amplification, compaction and which databases use each.
Database Indexing Explained
How database indexes work: B-tree and other types, composite and covering indexes, why queries ignore indexes, the write cost and checking with EXPLAIN.