Managed Databases
Intermediate 13 min read Managed Databases

NoSQL Databases

Scale-out stores for specific access shapes

NoSQL services (DynamoDB, Cosmos DB, Firestore/Bigtable) trade joins and ACID breadth for horizontal scale and flexible schemas. Choosing the right NoSQL store means matching access patterns, not just picking a name.

DynamoDBNoSQLCosmos DBFirestoreBigtabledocumentkey-value
Prerequisites: Relational Managed Databases
Before we start

What you will learn

  • Categorize document, key-value, wide-column and graph stores
  • Explain partition keys and hot partitions
  • Choose NoSQL over relational with evidence
In 60 seconds

NoSQL abandons joins for pre-shaped access: one primary-key get, range scans, or per-attribute queries. DynamoDB scales to any throughput with a partition key; Firestore is a serverless document store; Bigtable is a wide-column timeseries engine.

Introduction

What is this?

AWS DynamoDB: managed key-value + document, on-demand/provisioned capacity, global tables, stream triggers. Azure Cosmos DB: multi-model (document, table, graph, columnar) with consistency levels and global distribution. GCP Firestore: serverless document store with realtime sync; Bigtable: wide-column petabyte timeseries. All scale horizontally by partition key; hot keys and poor access patterns cause throttling.

Motivation

Why do you need it?

  • Predictable sub-10ms single-key reads at any scale.
  • No schema migration for evolving documents.
  • Serverless billing (DynamoDB on-demand, Firestore) fits spiky apps.
  • Global distribution (global tables, multi-region Cosmos) with strong consistence choice.
Think about it

Mental model

Imagine

A coat check where every tag maps straight to a hook

Think of

Key-value NoSQL

Fast when you know the tag (primary key). Searching 'all coats by color' (a scan/query without the key) is possible but costs a rack of hangers — exactly why access calls are designed up front.

Mechanics

How it works

  • Data model: item/partition key (HASH) + optional sort key (RANGE) define the index.
  • Partitions each hold a key range; a hot key concentrates traffic onto one partition and throttles it (partition key design is everything).
  • Queries read by key (GetItem) or across a sort-key range (Query); scans touch everything and cost reads linearly.
  • Consistency: eventually/strong options per store; Cosmos exposes consistency levers.
  • DAX/Cache proxies buffer hotspots; exponential backoff with retries mitigates, not fixes, hot keys.

Partitioned access path.

Item
Hash(PK)
Partition store
Hot key?
Throttle/scale
Hands-on

Examples

Design for partition access

Design for partition access
# DynamoDB: item-by-primary-key plus range query
Item:  {"pk": "user#42", "sk": "order#2026-09-22T01:00:00Z", "amount": 9.99}
# Query recent orders for a user (uses pk=sk range):
#   GetItem {pk: user#42, sk: order#2026-...}
# Bigtable: row key = time-bucketed metric -> time series
# row key "sensor#2026-09-22#01"

Composite keys bake in the access pattern: user# → their orders as a range scan.

Real world

In production

  • A chat app stores messages as sk=timestamp ranges per conversation on Firestore.
  • A logger round-trips metrics through Bigtable keyed by host#minute for fast scans.
  • Cosmos DB distributes a shopping-cart service across two regions with session consistency.
Guidelines

Best practices

  • Design access patterns before schema: the key IS the index.
  • Use high-cardinality partition keys; avoid 'user' on a table you'll 'scan all'.
  • Balance reads/writes: know your consistent needs and pick capacity mode accordingly.
  • Enable TTL for expiring sessions/logs instead of deleting manually.
Watch out

Common mistakes

  • Querying 'by email' without an email index → full scan on every login.
  • Hot partition from one celebrity key throttling the whole table.
  • Believing 'NoSQL = no schemas' — access patterns still need design.
  • Choosing NoSQL for strongly-acid financial balance semantics then bolting on hacks.
Root cause analysis

Common issues

Error
One key throttles everything
Root cause

Partition key with low cardinality or skewed popularity

Fix

Redesign the key to spread load (add salt/entity suffix), or warm a secondary index for reads.

Error
Expensive scans in the runner bill
Root cause

Access pattern without a supporting index

Fix

Model a GSI or second table keyed for the query; never scan a large table habitually.

When things break

Debugging tips

  • Throttled 'ProvisionedThroughputExceeded': inspect hot keys — Enable CloudWatch metric on item-level throttling.
  • Scans slow: add a GSI (Global Secondary Index) for the query column.
  • Latency spikes: check partition distribution — skew shows in table resource metrics.
  • Consistency confusion: read-after-write lag → bump consistency level or design around eventual reads.
Interviews

Interview checkpoint

Practice

Hands-on lab

Design and Stress a NoSQL Access Pattern
30 min · intermediate
In progress
Objectives
  • Model items with a good PK/SK scheme
  • Simulate hot-key throttling
  • Fix the design with a high-cardinality key

Design and Stress a NoSQL Access Pattern

30 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

What makes a DynamoDB partition key 'good'?

Go deeper

Official documentation

AWS — DynamoDB
docs
Azure — Cosmos DB
docs
GCP — Firestore and Bigtable
docs