Azure Cosmos DB

As applications spread globally, the physical location of the database starts shaping user experience directly. Teams then face a difficult combination of scale, flexible schemas, replication, and consistency. Building those concerns manually quickly turns into a distributed systems project of its own.

Traditional relational databases were not designed for the combination of massive horizontal scale and global low-latency access that modern internet products demanded. Distributed NoSQL systems emerged to absorb that pressure, and Cosmos DB extends that pattern by pushing much of the replication and scaling machinery into the platform itself.

Cosmos DB distributes data through partition keys. Logical partitions are mapped onto physical partitions, and the service expands those partitions as data or traffic grows. Throughput is modeled through request units (a normalized measure of CPU, memory, and IO cost per operation), and consistency can be chosen along a spectrum so teams can balance latency against freshness requirements.

Cosmos DB and Azure SQL Database are both Azure databases, but they are built around different trade-offs. Cosmos DB favors globally distributed, independently addressable records and schema flexibility. SQL Database favors relational structure, richer joins, and broader transactional semantics.

Cosmos DB is a strong fit for globally accessed catalogs, user settings, feeds, session-like records, and high-volume event ingestion where independent items scale better than tightly joined relational rows. It is less natural when broad multi-entity transactions or strongly relational access patterns are central to the workload.