Azure Cosmos DB: APIs, Request Units, and Availability
Cosmos DB is a globally distributed, highly scalable, non-relational database service built for low latency and high availability with a comprehensive SLA. It addresses consistency problems directly and aims for sustained performance regardless of location or demand. It's also aimed squarely at database developers rather than Azure administrators — configuring it well takes application-level knowledge, and several of its most consequential settings are chosen once, at account creation, and can't be changed afterwards.
What it guarantees
There's no single point of failure. Cosmos DB keeps four copies of your data within a zone — a primary plus three replicas on other nodes in the same data centre — and maintains quorum across those replicas, which is how it survives individual node failures without any application change or configuration.
It handles fluctuating demand without degradation, eliminating performance highs and lows. It guarantees low-latency access regardless of user location, with single-digit millisecond response times. And it preserves session state: if the instance a user is connected to has a problem, the session moves to another instance with the order of operations intact.
Data structures can be modified freely over time — new properties and objects added at any point — and it supports complex data relationships.
The account name must be globally unique within Azure.
Choosing an API
Cosmos DB is multi-model, supporting NoSQL, MongoDB, PostgreSQL, Cassandra, Gremlin, and Table. The API you choose determines the data model and the query language, letting applications treat Cosmos DB as though it were another database technology without the management and scaling overhead of running that technology.
- The API for NoSQL — historically called Core (SQL) — is the general-purpose option, and the one to pick unless something specific pulls you elsewhere.
- The others exist mainly for compatibility: pointing existing MongoDB, Cassandra, or Gremlin code at Cosmos DB with minimal change.
- PostgreSQL is the one to avoid for new work. Microsoft's documentation describes Azure Cosmos DB for PostgreSQL as on a retirement path and no longer recommended for new projects, and points PostgreSQL workloads to the elastic clusters feature of Azure Database for PostgreSQL instead.
Two clarifications worth making, because they come up as distractors: Cassandra is a NoSQL database, and the MongoDB API supports document-based storage rather than relational models. You can't use the Cassandra API against Azure SQL Database, SQL Managed Instance, or Data Lake Storage — the API belongs to Cosmos DB, not to those services.
This choice is effectively permanent for the data model. Changing it later means migrating data, not flipping a setting.
Capacity mode
Capacity mode defines how throughput — measured in request units per second (RU/s) — is managed.
- Provisioned throughput guarantees predictable performance for critical workloads. You reserve capacity and pay for it whether or not you use it.
- Serverless is cost-effective for infrequent or unpredictable workloads, billing for consumption rather than reservation.
The distinction mirrors the provisioned-versus-serverless choice elsewhere in Azure: reserve capacity when load is steady enough to predict, consume it when it isn't.
The free tier gives the first 1,000 RU/s and 25 GB of storage free for the lifetime of the account, with one free-tier account per subscription. It's not available for serverless accounts, and it has to be chosen at creation — you can't apply it afterwards.
Course material frequently gives the free tier as 400 RU/s and 5 GB. That's a conflation with the separate Azure free account offer, which provides 400 RU/s and 25 GB for 12 months. The two stack: use both and you get 1,400 RU/s and 50 GB for the first year, then 1,000 RU/s and 25 GB for the lifetime of the account.
Availability and what it costs
Availability scales with how much redundancy you buy, and so does the bill:
| Configuration | Availability |
|---|---|
| Multi-region replication | 99.99% writes, 99.999% reads |
| Multi-write (multiple regions accepting writes) | 99.999% both |
| Availability zones, single region | 99.995% |
| Availability zones + multi-region | 99.995% writes, 99.999% reads |
The cost curve is steep enough to state plainly: availability zone support is charged at a premium — waived for accounts configured with multi-region writes and for containers using autoscale throughput — and multi-region deployment multiplies cost by 2x, 3x, or more depending on how many regions you add. Both apply to throughput, which is usually the dominant line on a Cosmos DB bill — so a decision that looks like a resilience choice is also a budget decision.
Zone redundancy is worth taking where available, particularly for single-region accounts. Because availability zones are physically separate with distinct power, networking, and cooling, the SLAs for zone-redundant accounts are higher than for accounts without them. An account that isn't zone-redundant may have all its replicas in one zone.
Backup
Two modes, and they're not equivalent:
Continuous backup provides self-service point-in-time restore, with three retention tiers — 7, 30, or 35 days. The 7-day tier carries no backup storage charge; the 30- and 35-day tiers do, and every restore is charged. You can switch between tiers, but switching to a shorter window can lose data beyond it. Backups are stored in locally redundant storage by default, or zone-redundant where the region has availability zones. Restore always creates a new account — you can't restore in place.
Periodic backup enforces a minimum backup interval of an hour, isn't point-in-time, and requires a support ticket to restore. That last point is the one that matters during an incident.
Two limitations on continuous backup: the Cassandra API isn't supported, and firewall, virtual network, RBAC assignments, stored procedures, triggers, and UDFs aren't restored — they have to be reapplied afterwards.
Where it's used
Cosmos DB suits applications needing high availability, consistent performance, and flexible data models. Four domains dominate:
Retail and marketing. Microsoft's own e-commerce platform behind the Windows Store and Xbox Live runs on it. It holds catalogue data describing people, places, and products, user account information for authentication, and product catalogues. The automotive parts supplier case makes the schema argument concrete: a product catalogue where each part has different attributes, and new attributes appear whenever a new version of a product ships, is painful in a fixed schema and natural in a flexible one.
Internet of Things. Ingesting, processing, and storing sensor data — a trucking company with sensors in refrigerated trailers monitoring temperature, reporting to Azure for real-time monitoring, alerting, and automated service tickets, with the data archived for later trend analysis. It integrates with IoT Hub, Stream Analytics, Notification Hubs, Machine Learning, and Power BI.
Social applications. Global scale with unpredictable usage, storing and querying user-generated content — chat messages, posts, comments, ratings, reviews — as freeform text, properties, and tags.
Gaming. Game data, high-graphics delivery, and low-latency experiences. Real-time online gameplay needs single-millisecond latency; Halo 5 and Walking Dead: No Man's Land both use it.
Global distribution in practice
Users reach a web app through a browser, the app connects to Cosmos DB, and logging goes to an Azure storage account. For globally distributed applications, a traffic manager directs users to the nearest available Cosmos DB instance across regions, giving both lower latency and load balancing.
For multi-write accounts, writes in the hub region are confirmed immediately; writes in satellite regions are sent to the hub for confirmation and conflict resolution before being acknowledged. That asymmetry matters when reasoning about what a restore will contain — only data confirmed by the hub at the restore timestamp is restored.
Creating an account
The decisions that actually matter, in the order the portal asks them:
- Account name — globally unique within Azure.
- API — effectively permanent for the data model.
- Region — close to your users.
- Capacity mode — provisioned for predictable critical workloads, serverless for light or unpredictable traffic.
- Free tier — 1,000 RU/s and 25 GB, one per subscription, chosen at creation only.
- Account type and geo-redundancy — these drive both cost and availability.
- Networking — public or private, plus firewall rules.
- Backup policy — continuous or periodic, and the retention tier.
- Encryption — service-managed key, or customer-managed key from Key Vault.
Account creation typically takes 10–15 minutes, during which you shouldn't make changes.
Analytics over Cosmos DB data used to mean enabling Azure Synapse Link on the account and querying the analytical store from Synapse. Microsoft's documentation now says Synapse Link is no longer supported for new projects and not to use it; the replacement is Cosmos DB mirroring for Microsoft Fabric, which is generally available. The analytics side of that move is covered in the post on Data Lake Storage, Databricks, and Synapse.
Sources
- Welcome to Azure Cosmos DB — Microsoft Learn
- Choose an API in Azure Cosmos DB — Microsoft Learn
- Azure Cosmos DB lifetime free tier — Microsoft Learn
- Continuous backup with point-in-time restore — Azure Cosmos DB | Microsoft Learn
- Reliability in Azure Cosmos DB — Microsoft Learn
- Analytics with Azure Synapse Link — Azure Cosmos DB | Microsoft Learn
- Introduction to Azure Cosmos DB for PostgreSQL — Microsoft Learn