Learn Azure's globally-distributed NoSQL database by doing: create an account and container with the right partition key, write and query items, model data for your access patterns, and tune throughput.
Cosmos DB is a fully-managed NoSQL database that stays fast at any size and can replicate across regions. Unlike SQL there are no joins, and you design around how you will READ the data. Why: choosing the right partition key so queries hit one partition is the single most important decision — it determines speed and cost.
Create a Cosmos DB account using the Core (NoSQL) API
az cosmosdb create \
--resource-group learn-rg \
--name learn-cosmos-7f3k \
--kind GlobalDocumentDB \
--default-consistency-level SessionA Cosmos account holds databases; a database holds containers; a container holds items (JSON documents). Why the container is the key unit: throughput and the partition key are set per container, and items in one container need not share the same shape.
Create a database
az cosmosdb sql database create \
--resource-group learn-rg --account-name learn-cosmos-7f3k \
--name appdbCreate a container with /userId as the partition key
az cosmosdb sql container create \
--resource-group learn-rg --account-name learn-cosmos-7f3k \
--database-name appdb --name orders \
--partition-key-path /userId \
--throughput 400The partition key decides how items are grouped and spread across the database. Why it matters: queries that filter by the partition key are cheap and fast (they touch one partition); queries without it fan out across all partitions and get slow and expensive. Pick a key your common queries always include — like userId.
A good partition key: - has many distinct values (high cardinality) -> spreads load evenly - appears in most of your queries -> queries stay cheap Here /userId means "all of one user's orders live together" — perfect for "get this user's orders" and write-heavy workloads.
echo "Choose the key your most common query always filters on."You create items as JSON and read them by id within their partition. Why supply the partition key on reads: Cosmos uses it to jump straight to the right partition instead of scanning — that is what keeps point reads in single-digit milliseconds.
Create an item (note: it must include the partition-key field userId)
az cosmosdb sql container item create \
--resource-group learn-rg --account-name learn-cosmos-7f3k \
--database-name appdb --container-name orders \
--partition-key-value u-100 \
--body '{"id": "order-1","userId": "u-100","total": 42.50,"status": "shipped"}'Run a query for one user's orders (stays within a single partition)
az cosmosdb sql query \
--resource-group learn-rg --account-name learn-cosmos-7f3k \
--database-name appdb --container-name orders \
--query-text "SELECT * FROM c WHERE c.userId = 'u-100'"Cosmos measures capacity in Request Units per second (RU/s) — every read and write costs RUs. Two modes: provisioned (you set RU/s; cheaper for steady load, and can autoscale) and serverless (pay per request; best for spiky or unknown traffic). Why: pick serverless while learning, switch to provisioned autoscale for production.
Switch the container to autoscale, capped at 4000 RU/s
az cosmosdb sql container throughput update \
--resource-group learn-rg --account-name learn-cosmos-7f3k \
--database-name appdb --name orders \
--max-throughput 4000Cosmos can replicate your data to multiple regions with a single setting, putting data close to users worldwide. It also takes automatic backups. Why: adding a region improves read latency abroad and provides failover; backups protect against accidental data loss.
Add a second read region for lower latency elsewhere
az cosmosdb update --resource-group learn-rg --name learn-cosmos-7f3k \
--locations regionName=eastus failoverPriority=0 isZoneRedundant=False \
--locations regionName=westeurope failoverPriority=1 isZoneRedundant=False