Azure SQL Database & Cosmos DB

Azure Fundamentals

Chapter 6 · Azure SQL Database & Cosmos DB

AWS Fundamentals Chapter 6 covered RDS and DynamoDB — a relational option and a NoSQL option, each fairly focused in scope. Azure's own two flagship database services genuinely diverge from that pattern in real, specific ways: Azure SQL Database offers a real, explicit choice of billing philosophy, and Cosmos DB offers real capabilities DynamoDB simply doesn't.

Azure SQL Database: Two Real Purchasing Models

Azure SQL Database offers a real, deliberate choice between two genuinely different ways of buying compute:

DTU-based — a real, blended, single unit (a Database Transaction Unit) bundling CPU, memory, reads, and writes together into simple, preconfigured tiers (Basic, Standard, Premium). Genuinely simpler, with fixed monthly bundles, but no independent control over any one resource.
vCore-based (Microsoft's own recommended default) — independently choose compute (vCores), memory, and storage, across three real service tiers: General Purpose, Business Critical, and Hyperscale. Also offers a real serverless compute option, which automatically pauses (billing only for storage) during genuine inactivity, and automatically resumes when activity returns.

A Real, Specific Cost Detail

The Business Critical tier automatically provisions three additional real replicas for higher availability and lower-latency local SSD storage — as a direct, real consequence, it costs roughly 2.7 times more than the equivalent General Purpose tier. This isn't an arbitrary price difference; it's the real, documented cost of the extra infrastructure Business Critical actually provisions on your behalf.

Cosmos DB: A Real 2017 Launch

Azure Cosmos DB released in 2017 as a real, globally distributed, multi-model database service — genuinely more ambitious in scope from the outset than DynamoDB's own single, focused key-value/document model (AWS Fundamentals Chapter 6).

A Real, Genuine Differentiator: Multi-Model APIs

Cosmos DB exposes the same underlying data through real, multiple wire-compatible APIs, letting an application use whichever query language it already knows:

API	Real Compatibility
SQL (Core) API	Cosmos DB's own native, JSON-friendly query language
MongoDB API	Wire protocol version 6, server version 3.6
Cassandra API	Cassandra Query Language (CQL) wire protocol v4
Gremlin API	Graph queries, Gremlin specification v3.2
Table API	Azure Table Storage compatibility
etcd API	etcd wire protocol v3

DynamoDB has no real equivalent to this — it exposes exactly one, DynamoDB-specific API. An application already built against MongoDB or Cassandra can move to Cosmos DB with far less real rework than migrating to DynamoDB would require.

A Real, Genuine Differentiator: Five Consistency Levels

AWS Fundamentals Chapter 6 covered DynamoDB's own simple, two-option consistency choice — strongly consistent or eventually consistent. Cosmos DB offers a genuinely richer, real five-level spectrum instead:

Strong — every read reflects the latest globally committed write.
Bounded Staleness — reads never lag beyond a real, configured number of versions or a specified time window.
Session (the real default) — guarantees a client always reads its own prior writes ("read-your-own-writes"), even if other clients might see slightly stale data.
Consistent Prefix — reads never see out-of-order writes, though they may lag behind the latest.
Eventual — no ordering guarantee at all; replicas converge eventually.

A Real, Meaningful Middle Ground

Cosmos DB's real default, Session consistency, solves a genuine, common problem neither of DynamoDB's own two options directly addresses as cleanly: guaranteeing a single client always sees its own writes immediately, without paying the real, full cost of Strong consistency for every reader globally.

RDS/DynamoDB vs. Azure SQL/Cosmos DB

Property	AWS (RDS / DynamoDB)	Azure (SQL DB / Cosmos DB)
Relational billing choice	Instance-size-based only	A real choice — DTU (bundled) or vCore (independent)
NoSQL API surface	One, DynamoDB-specific API	Six real wire-compatible APIs (SQL, MongoDB, Cassandra, Gremlin, Table, etcd)
Consistency options	Strong or Eventual (2 choices)	Strong, Bounded Staleness, Session, Consistent Prefix, or Eventual (5 choices)
Real default consistency	Eventual	Session

Hands-On Exercises

Exercise 1

A team wants the highest real availability and lowest latency for a critical Azure SQL Database workload, and is comparing Business Critical against General Purpose. Explain, in your own words, why Business Critical costs roughly 2.7 times more, rather than treating it as an arbitrary price markup.

📄 View solution

Exercise 2

A team has an existing application built against the MongoDB API and wants to migrate to a managed cloud database with minimal code changes. Explain, in your own words, why Cosmos DB is a genuinely better real fit here than DynamoDB.

📄 View solution

Exercise 3

A client needs to reliably read back its own just-written data, but the team doesn't want to pay the real cost of Strong consistency for every reader globally. Explain, in your own words, why Cosmos DB's real Session consistency level (the default) fits this need better than either of DynamoDB's own two consistency options would.

📄 View solution

Chapter 6 Quick Reference

Azure SQL Database — real DTU (bundled) vs. vCore (independent, with a real serverless auto-pause option) purchasing models
Real cost detail: Business Critical costs ~2.7x General Purpose, due to three real automatically-provisioned extra replicas
Cosmos DB — released 2017, real multi-model support (SQL, MongoDB, Cassandra, Gremlin, Table, etcd APIs)
Five real consistency levels — Strong, Bounded Staleness, Session (default), Consistent Prefix, Eventual — genuinely richer than DynamoDB's two-option model
Session consistency's real "read-your-own-writes" guarantee fills a genuine gap between DynamoDB's own Strong and Eventual options