NexisyTech Learningby Nexisy Technologies

SQL vs NoSQL

Relational, document, key-value, wide-column and graph databases — match the store to the access pattern.

Beginner8 min read3 interview questions

Relational (SQL) databases store data in tables with a fixed schema, joins and ACID transactions. They are the right default for most business systems.

NoSQL databases trade some of that structure for flexible schemas, horizontal scale or a data model that fits a specific access pattern. The question is not “which is better” but “how will this data be read and written?”.

Diagram

How is the data accessed?Relationaljoins, transactionsDocumentJSON aggregatesKey-valueget / set by keyWide-columnhuge write volumeGraphrelationshipsPostgreSQL, SQL ServerMongoDB, Cosmos DBRedis, DynamoDBCassandraNeo4j
Five database families and typical examples of each.

Key concepts

Schema-on-write
SQL validates structure when data is written. Errors are caught early.
Schema-on-read
Document stores accept varying shapes; the application interprets them.
Aggregate
A cluster of data read and written together, such as an order and its lines — a natural document.
Polyglot persistence
Using different stores for different needs in one system, e.g. SQL for orders, Redis for sessions, a search engine for products.
NewSQL
Distributed databases with SQL and ACID that scale horizontally, such as CockroachDB or Spanner.

Trade-offs

Benefits

  • SQL: integrity, rich queries, mature tooling
  • Document: flexible schema, natural fit for aggregates
  • Key-value and wide-column: massive scale and predictable latency

Costs

  • SQL: harder to shard, schema changes need migrations
  • NoSQL: weaker ad-hoc querying and joins
  • NoSQL: consistency and transactions vary by product

Use it when

  • SQL for transactional business data with relationships
  • Document stores for content and per-entity aggregates
  • Key-value for sessions, caching, feature flags
  • Wide-column for time-series, IoT and event logs
  • Graph for social networks, recommendations, fraud rings

Common mistakes

  • Choosing NoSQL “for scale” when the dataset fits easily on one SQL server
  • Modelling relational data in a document store and re-implementing joins in code
  • Ignoring how you will query the data before picking the store

Interview questions

Q1An e-commerce system needs orders, a product search and shopping carts. Which stores would you use?
A relational database for orders and payments (transactions), a search engine such as Elasticsearch for product search, and a key-value store such as Redis for carts and sessions.
Q2What does denormalisation mean in NoSQL?
Storing data duplicated in the shape it is read — for example embedding the customer name in each order — to avoid joins. The cost is updating multiple copies.
Q3Can relational databases scale horizontally?
Yes, with read replicas, sharding (e.g. Citus, Vitess) or distributed SQL engines, but it takes more effort than with databases designed to shard.

Related lessons

Data & Storage

CAP Theorem & Consistency

During a network partition, a distributed store must choose between consistency and availability.

Intermediate8 min read Data & Storage

Indexing & Query Performance

How indexes turn full table scans into fast lookups — and the other habits that keep queries quick.

Intermediate9 min read Data & Storage

Sharding Strategies

Range, hash, consistent hashing and directory-based sharding — how data is split across servers.

Advanced10 min read