Stop 06 · Database ServicesTopics · 2/10

NoSQL Databases (DynamoDB, Cosmos DB)

In short

When an app needs millions of fast lookups a second, like carts during a sale, a key-value database shines. But it only stays fast if you design around how you'll read the data.

Fully managed, highly scalable key-value/document databases designed for massive scale and low-latency access — a different data modeling approach from relational databases, optimized for specific access patterns.

The blob character points to one tagged clothing bundle at a laundry shop.

Think of it like this

The dhobi's tagged bundles

The laundry shop stacks bundles by room number. Ask for room 214 and he hands it over instantly. Ask for 'every blue shirt in the hostel' and he has to open every bundle. NoSQL databases work exactly like that.

Watch it happen

Query by key vs scan everything

u17

u42

u58

u91

1/5An Orders table. Each item's partition key is userId, and orderId sorts items within a user.

The big ideas

What you need to know

Design for access patterns

List the questions your app asks first, then choose keys that answer them directly. Schema follows queries.

Scale without servers

DynamoDB spreads data across partitions automatically. No instance sizes; you pay per request or for set capacity.

Flexible items

Items in one table can have different attributes. Only the key attributes are required.

No easy joins

There are no JOINs. Related data is often stored together or duplicated on purpose to keep reads to one request.

See it in code

Walk through the code

python

1import boto32from boto3.dynamodb.conditions import Key3 4table = boto3.resource("dynamodb").Table("Orders")5 6table.put_item(Item={"userId": "u42", "orderId": "2026-10-27#001", "total": 349})7 8# Fast: exact partition key, results sorted by orderId9resp = table.query(KeyConditionExpression=Key("userId").eq("u42"))10print(resp["Items"])11 12# Avoid on big tables: scan reads every item, then filters13# table.scan(FilterExpression=Attr("total").gt(300))

1/4Get a handle to the Orders table using the higher-level resource API.

The table has userId as partition key and orderId as sort key. Putting a date first in orderId keeps a user's orders in time order.

Save yourself the pain

Common mistakes

Oops

Designing NoSQL tables like normalised SQL tables, then needing joins.

Do this instead

Start from access patterns. Store what you read together in one item or one partition.

Oops

Using a partition key most requests share, like 'country = IN'.

Do this instead

A hot key funnels traffic into one partition. Pick high-variety keys like userId or orderId.

Your mission

Model a hostel mess app

~30 min

Quick check

Your DynamoDB queries are slow and costly because they use scan with a filter on 'email'. Best fix?

Go deeper

1Create a simple table in a managed NoSQL service and perform basic CRUD operations.
2Learn why NoSQL data modeling starts from your access patterns, not your entities, unlike relational design.
3Understand when NoSQL's flexibility is worth the trade-off of weaker query flexibility.