Intermediate 15 min read

Relational vs. NoSQL: Choosing the Right Database

By the end of this lesson, you'll be able to:

  • Compare the relational and NoSQL data models covered earlier in this module, side by side
  • Choose an appropriate database family for a described workload, based on its access pattern
  • Explain why the comparison is about fit, not about one family being universally superior

Prerequisites: "Amazon Aurora"

Bringing the two families together

This module has now covered both families this course focuses on: relational (RDS and Aurora, built around tables, relationships, and SQL) and NoSQL (DynamoDB, built around items grouped by a partition key). Neither is a replacement for the other — they solve different shapes of problem.

Side by side

Side-by-side comparison of a relational database with Customers and Orders tables joined by a foreign key, described as a strong fit for complex queries across related entities, and a NoSQL DynamoDB table with flexible items grouped by a partition key, described as a strong fit for fast lookups by a known key.
Not every NoSQL database looks like DynamoDB internally — this compares DynamoDB specifically, the one this course covers.
  • Relational (RDS / Aurora) — fixed schema, relationships enforced between tables, flexible querying across those relationships via SQL. Strong fit: structured data with genuine relationships and reporting/query needs that aren't fully known upfront.
  • NoSQL (DynamoDB) — flexible item shape, organized around a partition key chosen for a known access pattern. Strong fit: high-volume, predictable lookups by a known key, where the access pattern is understood in advance.

Working through two scenarios

  1. Karoo Retail's customer and order reporting (from Lesson 2) — orders belong to customers, and reporting needs to join across both, sometimes in ways not fully known upfront. This points toward relational.
  2. The device-monitoring event log (from Lesson 3) — a very high volume of independent events, looked up almost always by a known device ID. This points toward NoSQL.

Neither scenario makes the other database family "wrong" in general — each one is simply a poor fit for the other scenario's access pattern.

The decision question, distilled

When choosing between them for a real workload, the load-bearing question is: do you need flexible querying across relationships that aren't fully known in advance (lean relational), or do you have a known, dominant access pattern you can look up by a key quickly (lean NoSQL)? This isn't a permanent, irreversible choice for every application forever — some real systems use both, for different parts of their data — but it's the right first question to ask, rather than defaulting to whichever service is more familiar.

Exercise

A ticket-booking system needs to: (a) enforce that a booking belongs to exactly one customer and one event, and support ad-hoc reporting queries the business hasn't fully defined yet, while a separate part of the same company needs to (b) store and instantly retrieve a user's current session state by session ID, at very high volume. Which database family fits each part, and why?

Show hint

One part needs relationships and flexible querying; the other needs one clear key and speed.

Relational vs. NoSQL: Choosing the Right Database Quiz

1. A workload's dominant need is fast, predictable retrieval of an item by a known ID, at very high volume, with no need for cross-entity querying. Which database family best fits this?

2. One database family (relational or NoSQL) is generally the better choice for every workload, regardless of its access pattern.

Log in to submit the quiz and save your score.

My Notes

Log in to keep private notes on this lesson.

Questions about this lesson

No questions yet — be the first to ask.

Log in to ask a question about this lesson.

Summary

Relational databases (RDS, Aurora) suit structured data with meaningful relationships and flexible querying needs, while DynamoDB suits workloads dominated by fast, predictable lookups by a known key — the right choice comes from the workload's actual access pattern, not from one family being generally better than the other.

Log in to track progress
❬ Previous Next ❭