When to use NoSQL: MongoDB, Redis and DynamoDB

A relational database such as PostgreSQL is the right default for most backends: tables, rows, joins and transactions. But sometimes your data or your traffic fits a different shape better. "NoSQL" is a loose name for databases that are not built around tables and SQL. It is not one thing. It covers several very different designs, and choosing between them is a common interview question.

In this lesson you will learn the main NoSQL families, how MongoDB, Redis and DynamoDB each work, and a simple way to decide. You should already know basic SQL (see *SQL and PostgreSQL for backend developers*). Using Redis as a cache is practised in *Caching with Redis*.

This lesson focuses on the three you will meet most in job postings: MongoDB (document), Redis (key-value, in memory) and DynamoDB (key-value and document, managed by AWS).

Think of a filing cabinet where each folder is a self-contained document. In MongoDB a document is a JSON-like object, and a collection is a group of documents (like a table, but without a fixed set of columns).

A Brew & Bean order fits this well. In SQL you would split it across orders and order_items tables and join them. In MongoDB you can store the whole order, items included, as one document, and read it back in one go.

{
  "_id": "ord_1042",
  "customer_name": "Asha",
  "phone": "9876543210",
  "items": [
    {"item_id": "cappuccino", "qty": 2, "price": 180},
    {"item_id": "banana-bread", "qty": 1, "price": 130}
  ],
  "total": 490,
  "status": "received",
  "created_at": "2026-10-31T09:15:00Z"
}

Items are embedded inside the order. Reading the order needs no join.

# pip install pymongo
from pymongo import MongoClient

client = MongoClient("mongodb://localhost:27017")
orders = client["brewbean"]["orders"]   # database "brewbean", collection "orders"

orders.insert_one({
    "_id": "ord_1042",
    "customer_name": "Asha",
    "items": [{"item_id": "cappuccino", "qty": 2, "price": 180}],
    "total": 360,
    "status": "received",
})

print(orders.find_one({"_id": "ord_1042"}))

# Move the order to the next status
orders.update_one({"_id": "ord_1042"}, {"$set": {"status": "preparing"}})

# All orders that contain a cold brew
for o in orders.find({"items.item_id": "cold-brew"}):
    print(o["_id"])

# Fast lookups need an index, just like SQL
orders.create_index("status")

Needs a running MongoDB (local install, Docker, or a free-tier cluster on MongoDB Atlas). $set changes only the named field.

Strengths: flexible shape (two documents in a collection can have different fields), nested data read in one query, easy to start with, scales out across machines.

Weaknesses: joins across collections are awkward, so data that is shared between many records tends to be copied (duplicated), and keeping the copies in sync is your job. MongoDB does support multi-document transactions, but they are not the everyday path they are in PostgreSQL. Because the database does not enforce a schema by default, messy data can creep in unless you validate it in your code.

Redis is a database that keeps its data in RAM. That makes it extremely fast (a simple read is usually well under a millisecond), but RAM is small and costly compared with disk, and data held only in RAM can be lost if the server restarts unless you turn on Redis persistence options.

Think of a notice board next to the shop counter: instant to read, small, and you only pin up what is needed right now. Redis is used for caches, login sessions, rate-limit counters, leaderboards, queues and temporary data that can expire by itself.

redis-cli
> SET menu:espresso "120"
OK
> GET menu:espresso
"120"
> SET session:abc123 "user_42" EX 3600     # expires in one hour
OK
> TTL session:abc123
(integer) 3599
> INCR visits:today                          # atomic counter
(integer) 1
> INCR visits:today
(integer) 2
> HSET order:1042 status preparing total 490   # a hash: like a small object
(integer) 2
> HGETALL order:1042
1) "status"
2) "preparing"
3) "total"
4) "490"
> LPUSH queue:orders 1042                    # a list, usable as a simple queue
(integer) 1

Lines starting with > are what you type at the redis-cli prompt. Text after # is a comment for you.

Redis values are not only strings. Redis has built-in structures: hashes (field-value pairs), lists, sets, sorted sets (great for leaderboards) and more. Commands like INCR are atomic, so two requests incrementing the same counter at the same moment never lose an update.

Strengths: speed, simple commands, built-in expiry (EX, TTL), useful data structures.

Weaknesses: data must fit in memory, querying is by key (you cannot say "find all orders where status is ready" without building your own index), and it is usually a helper next to your main database, not the only store of important data.

DynamoDB is a database run by AWS. You do not install or patch servers; you create a table and AWS handles the machines, replication and scaling. You choose a partition key (and optionally a sort key), and every read is fast if you look an item up by that key.

For Brew & Bean you might use a table Orders with partition key customer_phone and sort key created_at. Then "all orders for this customer, newest first" is one fast query. The price of this speed is that you must design the table around your questions before you build it. Asking a new kind of question later (for example "all orders in status ready") may need a secondary index or a different design, and ad-hoc querying is far less flexible than SQL.

# pip install boto3     (also needs AWS credentials configured)
import boto3
from boto3.dynamodb.conditions import Key

dynamodb = boto3.resource("dynamodb", region_name="ap-south-1")   # Mumbai
table = dynamodb.Table("Orders")

table.put_item(Item={
    "customer_phone": "9876543210",
    "created_at": "2026-10-31T09:15:00Z",
    "status": "received",
    "total": 490,        # use int or Decimal, boto3 does not accept float
})

# Fast: query by partition key, newest first
result = table.query(
    KeyConditionExpression=Key("customer_phone").eq("9876543210"),
    ScanIndexForward=False,
)
for item in result["Items"]:
    print(item["created_at"], item["status"])

Assumes a table named Orders already exists with partition key customer_phone (string) and sort key created_at (string). boto3 rejects Python floats; use int or decimal.Decimal.

DynamoDB has a free tier on AWS at the time of writing (2026), but the details change, so check the AWS pricing page before relying on it. Costs depend on how much you read, write and store, so set a billing alert on any AWS account you use for learning.

A very common real design uses several together: PostgreSQL for the source of truth (orders, users), Redis to cache the menu and store sessions, and sometimes a document store for logs or flexible content. Using more than one database for different jobs is normal, and it is called polyglot persistence. Do not add one just to look modern: every extra database is one more thing to run, secure, back up and learn.

Interviewers rarely want a product war. They want to see that you pick a database from the access pattern and data shape. A strong answer to "SQL or NoSQL for an e-commerce app?" names what needs transactions (orders, payments), what is flexible (product attributes), and what is just speed (cart, sessions in Redis), and admits that starting with PostgreSQL is a sensible default. Other likely questions: what is the CAP theorem (when the network splits, a distributed system must choose between consistency and availability), what is a TTL, and why use an index.

I am building [describe your app, e.g. a food-delivery app for a college canteen]. Its main data is [list entities] and its main queries are [list the 5 most common reads and writes]. Compare PostgreSQL, MongoDB, Redis and DynamoDB for it. Give a recommendation with reasons tied to my queries, say what I would store where, and name one risk of your recommendation.

What to expect: A good answer ties each choice to your queries, picks a primary database, and uses Redis or similar only as a helper. Challenge any claim that sounds absolute.