The key characteristics of Azure Cosmos DB: schema-agnostic items, automatic indexing, global distribution and low latency.
From Ultra Transcenders DP-900 by Tony Rough (publishing soon)
Cosmos DB sits in the non-relational part of the exam. Understanding what makes it different from a relational database is the starting point for deciding when to use it.
Azure Cosmos DB is a fully managed NoSQL database service, offered as platform as a service (PaaS). NoSQL is the collective name for databases that store data in structures other than relational tables, such as documents, key-value pairs, column families and graphs (Chapter 1, Representing and storing data, describes these four types). PaaS means Microsoft runs the underlying infrastructure, including server provisioning, patching, updates and backups, so the customer only looks after the data and the application.
Key characteristics:
Two features are worth a sentence each. The change feed tracks changes to a container so that other services, such as Azure Functions, can react to them in event-driven designs. Vector search stores vector embeddings (numeric representations used by AI applications) alongside operational data, for scenarios such as AI agents and retrieval-augmented generation.
Common trap: Assuming Cosmos DB needs a schema and indexes defined before data is loaded, like a relational table - it is schema-agnostic and indexes every property automatically by default, so items with different shapes can share a container.
This note is one section of Ultra Transcenders DP-900: Microsoft Azure Data Fundamentals, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · DP-900 terms in the glossary · All DP-900 study notes
What each ACID property guarantees in a transactional (OLTP) database, with the classic funds-transfer example.
How extract-transform-load and extract-load-transform differ, and why ELT is common in modern lakehouses.
How OLTP and analytical systems differ in purpose, data shape, queries and users.
How normalisation splits data into one table per entity, linked by keys, so each fact is stored once.
The three Azure SQL options side by side: IaaS or PaaS, compatibility, management and availability.
Which Azure SQL option or open-source database service fits a requirement, and why.
Storage and access costs, minimum retention periods, Archive rehydration and lifecycle management policies.