Instiq
Chapter 3 · Non-relational Data on Azure·v2.1.0·Updated 6/11/2026·~14 min

What's changed: Added vector/semantic search (embeddings, RAG) to Cosmos DB to reflect the 2026 refresh’s AI emphasis in the non-relational domain.

3.1Non-relational Data and Azure Cosmos DB

Key points

Understand the four kinds of non-relational (NoSQL) data (key-value, document, column-family, graph), how they differ from relational, and the features, multiple APIs, and global distribution of Azure Cosmos DB.

A non-relational (NoSQL) database stores data flexibly, without a fixed schema. Where relational uses strict tables of rows and columns, NoSQL allows fields to differ per item, suiting large, varied data and scenarios needing high scalability. NoSQL is not one thing—it splits into four kinds by storage shape. Choose by "what shape is the data / what do you need to be fast."

3.1.1The four kinds of NoSQL

Diagram of non-relational store kinds: key-value (key→value, simple/fast, e.g., Table storage), document (JSON docs, flexible fields, e.g., Cosmos DB), column-family (rows with column groups, e.g., Cassandra API), and graph (nodes and edges for relationships, e.g., Gremlin API).
Kinds of non-relational (NoSQL) stores
  • Key-value: the simplest form—store a value per key; lookups by key are very fast. E.g., session info, caches.
  • Document: store JSON-like documents one at a time; fields can differ per document, very flexible. E.g., product catalogs, user profiles.
  • Column-family: rows organized into column groups, handling huge tables fast. E.g., large IoT datasets.
  • Graph: represent relationships with nodes and edges; great at traversing connections. E.g., social friendships, recommendations.
KindStorage shapeBest forExample (Cosmos DB API)
Key-valueKey → valueFast simple lookups, cachingTable API / Table storage
DocumentJSON documentsFlexible-attribute dataNoSQL (Core) / MongoDB API
Column-familyRows of column groupsLarge scale, high throughputCassandra API
GraphNodes and edgesTraversing relationshipsGremlin API

3.1.2How it differs from relational

Relational has a fixed schema and strong consistency, excelling at complex joins and strict transactions (ACID), but structural changes are heavy and horizontal scaling can be hard. NoSQL is schema-flexible and scales out easily, suiting huge or fast-changing data, but may be weaker at complex joins and strict consistency. Neither is universally better—choose by use case. Recall the prior mapping: "structured = relational," "semi-structured = NoSQL (document)."

3.1.3Azure Cosmos DB

  • Azure Cosmos DB is a fully managed NoSQL database with global distribution, low latency, and auto-scaling.
  • Supports multiple APIs: NoSQL (Core/document), MongoDB, Cassandra, Gremlin (graph), Table—pick to match an existing app’s API.
  • Can replicate to regions worldwide for low-latency access near users, with SLAs on throughput and latency.
  • Vector / semantic search: recently, for AI scenarios, Cosmos DB can store data as vectors (embeddings) and search by "semantic closeness" (used for grounding generative-AI apps, e.g., RAG).
Example

Scenario: a global e-commerce app. To respond with low latency worldwide → replicate Cosmos DB across regions. Product data with varied fields fits document (NoSQL API), the cart’s transient info fits key-value, and "people who bought this also bought…" relationships fit graph (Gremlin API). One app uses several data shapes.

Warning

Watch the mix-ups: (1) document (JSON, flexible attributes) vs key-value (simple value fetched by key). (2) When relationships are central, use graph (Gremlin). (3) Cosmos DB is non-relational—different role from Azure SQL (relational) in the previous chapter. (4) Cosmos DB’s "multiple APIs" means the same platform accessed via different APIs, not entirely separate engines.

Note

Q. Is NoSQL a superset of relational? No—relational excels at complex joins and strict consistency; choose by use case. Q. Which kind is Cosmos DB? Mainly document, but via multiple APIs it also serves key-value (Table), graph (Gremlin), and column-family (Cassandra). Q. Benefit of global distribution? Responding from a nearby region gives low latency and higher availability during failures.

Exam point

Common mappings: relationships = graph (Gremlin), JSON documents = document, fast key lookups = key-value, large scale/high throughput = column-family (Cassandra). Also remember Cosmos DB is multi-API, globally distributed, low-latency.

3.1.4Section summary

  • NoSQL = key-value (fast lookup) / document (JSON) / column-family (large scale) / graph (relationships)
  • Relational excels at consistency/joins; NoSQL at flexible schema/scale-out (choose by use case)
  • Cosmos DB = multi-API (NoSQL/MongoDB/Cassandra/Gremlin/Table), globally distributed, low-latency NoSQL

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. Which NoSQL store best represents "person-to-person connections" in a social network?

Q2. Which NoSQL kind fits storing flexible JSON documents?

Q3. Which is a feature of Azure Cosmos DB?

Q4. Which is the simplest NoSQL kind, fetching a value very fast by key?

Q5. Which is generally true of NoSQL compared with relational?

Check your understandingPractice questions for Chapter 3: Non-relational Data on Azure