Data Platforms in Azure, Part 1: Getting Started with Azure Cosmos DB

When people first look at data services in Azure, they usually know SQL Database or maybe Azure Data Lake. But Azure has a much broader family of data platforms designed for different use cases. In this series, I’ll walk through the major options—Cosmos DB, Data Lake, MySQL, PostgreSQL, and more—so you can see when to use each, how to get started, and what to watch out for.

Let’s kick off with Azure Cosmos DB, Microsoft’s globally distributed, NoSQL database service.

---

What is Azure Cosmos DB?

Cosmos DB is a multi-model database service that was built for applications needing speed, scalability, and global distribution. Unlike a traditional relational database, Cosmos DB is designed for:

• Low-latency reads and writes, typically under 10ms.
• Elastic scale—you can start small and grow to handle millions of requests per second.
• Multiple APIs, so you can use the programming model you already know:
  • Core (SQL API): Document model, queried with a SQL-like syntax.
  • MongoDB API: For apps already using Mongo drivers.
  • Cassandra API: Wide-column store compatibility.
  • Gremlin API: Graph database queries.
  • Table API: For key-value scenarios.

Reference: Microsoft’s Cosmos DB overview

For this post, I’ll stick with the SQL API because it’s the easiest entry point.

---

Setting Up Cosmos DB

Step 1: Create an account

You can do this through the portal or CLI. Portal steps:

1. In the Azure portal, click Create a resource → Databases → Azure Cosmos DB for NoSQL.
2. Fill in:
   • Resource Group: e.g. rg-cosmosdemo
   • Account Name: must be unique, e.g. cosmosdemo123
   • Location: choose a region close to your users.
   • Capacity mode: Start with Serverless if you’re experimenting; otherwise, Provisioned throughput gives you more control.

Step 2: Create a database and container

Cosmos DB uses a three-layer structure:

• Account → Database → Container → Items

Think of a container like a “table” (though it’s schemaless).

Example (CLI):

az cosmosdb sql database create \
  -a cosmosdemo123 \
  -g rg-cosmosdemo \
  -n appdb

az cosmosdb sql container create \
  -a cosmosdemo123 \
  -g rg-cosmosdemo \
  -d appdb \
  -n users \
  -p "/userid" \
  --throughput 400

Here, /userid is the partition key—a critical design choice. Partition keys determine how data is distributed and how queries scale.

---

Loading and Querying Data

Insert items

Once your container is created, you can add JSON documents. Example user profile:

{
  "userid": "u123",
  "name": "Lynn",
  "email": "lynn@example.com",
  "joined": "2025-09-01",
  "tags": ["esports", "coach"]
}

The key differences:

• Documents are schemaless, so not all items have the same fields.
• Functions like ARRAY_CONTAINS handle nested structures.

Reference: Cosmos DB SQL query syntax

---

Scaling and Performance

Cosmos DB is priced based on Request Units (RUs). Every query or write consumes RUs.

• 400 RU/s is the minimum for provisioned throughput.
• A simple point read (SELECT * FROM c WHERE c.id="123") costs 1 RU.
• Complex queries with filters, ORDER BY, or aggregates will cost more.

Tip: Always design with a good partition key. A bad partition key (like /country if most users are in the same country) can create “hot partitions” and kill performance. A good one distributes evenly (like /userid).

---

Global Distribution

One of Cosmos DB’s headline features is multi-region writes. You can enable replication to any Azure region with a few clicks.

• Writes and reads automatically go to the closest region.
• If one region fails, Cosmos DB fails over seamlessly.

CLI example to add a secondary region:

az cosmosdb update \
  -g rg-cosmosdemo \
  -n cosmosdemo123 \
  --locations regionName=eastus failoverPriority=0 \
               regionName=westus failoverPriority=1

Security Basics

• Encryption: All data is encrypted at rest by default.
• Network: Use private endpoints for secure connectivity.
• Auth: Use Azure AD or resource tokens rather than hard-coded keys.

---

When to Use Cosmos DB

Choose Cosmos DB when you need:

• Low-latency global reads and writes.
• Elastic scaling with guaranteed SLAs.
• Flexible schema with JSON documents.
• Multi-model support (SQL, Mongo, Cassandra, Gremlin, Table).

Avoid Cosmos DB if:

• You need heavy relational joins or complex transactions.
• You’re storing large binary blobs (use Blob Storage or Data Lake instead).

---

Wrap-Up and Next Steps

Cosmos DB is Azure’s answer to high-scale, low-latency NoSQL workloads. You can start small in serverless mode, load some JSON, and query it with SQL-like syntax. As you scale, you’ll lean on partition keys, RUs, and global distribution.

In Part 2 of this series, I’ll cover Azure Data Lake, focusing on how it’s different from Blob Storage and how you can use it as the backbone for big data analytics.

---

References

• Cosmos DB Introduction
• Cosmos DB SQL Query Examples
• Partitioning in Cosmos DB
• Request Units explained

Workshop: Hands-On with Cosmos DB

Goal: Build a working demo of Azure Cosmos DB using the SQL API and visualize data performance.

Prerequisites:

• Azure subscription (free tier works fine)
• Azure CLI installed
• VS Code or Azure Data Studio

Step 1: Create the Cosmos DB environment

1. Open the Azure portal.
2. Create a new resource group named rg-cosmoslab.
3. Deploy a new Cosmos DB account for NoSQL, named cosmoslab123.
4. Select Serverless for capacity mode.

Step 2: Load sample JSON data

1. Open VS Code and connect to the Cosmos DB extension.
2. Create a new database demoapp and container players.
3. Insert the following JSON:

{
  "playerid": "p001",
  "name": "Luke",
  "rank": "Legendary",
  "points": 1500,
  "team": "Valhallan"
}

4. Run a query:

SELECT c.name, c.points FROM c WHERE c.points > 1000

Step 3: Analyze performance

• Monitor RU consumption in the Azure Portal under Metrics → Throughput (RU/s).
• Experiment by adding more items and checking latency differences.

Step 4: Extend with global replication

• Add a secondary region (e.g., westus2) using CLI or the portal.
• Test failover by simulating a regional outage and observing continuity.

Step 5: Visualize results

• Export container data to Azure Data Explorer or Power BI for reporting.
• Build a quick dashboard showing player rank and performance trends.

Outcome:
By completing this workshop, you’ll have a fully functional Cosmos DB instance with real JSON data, replication enabled, and performance metrics ready for visualization.