Every post on my blog so far has used Azure SQL - a relational database with a fixed schema, queried with standard SQL. That has been the right choice for the blog's Posts table, which is tabular and consistent in shape. But not every kind of data fits neatly into rows and fixed columns, and not every kind of content belongs in a database row at all. At Blue Yonder, I used Cosmos DB to hold operational and application data from an Azure-based integration platform, querying it with KQL to support troubleshooting and reporting - a genuinely different use case from a primary transactional database, and a good illustration of just how flexible the document model can be. This post covers the two Azure services worth reaching for when SQL genuinely is not the right fit: Cosmos DB for flexible, fast-changing JSON documents, and Blob Storage for files.

What Azure Cosmos DB Actually Is

Azure Cosmos DB is a fully managed NoSQL database built for global distribution and elastic scale. Instead of rows constrained to fixed columns, it stores JSON documents - and critically, each document can have a different shape from the next, even within the same container.

Azure SQL is a filing cabinet with labeled folders and a fixed form inside each one - every form has the same fields in the same order, every single time. Cosmos DB is closer to a box of index cards, where each card can hold completely different information structured however makes sense for that one card, while still letting you flip through the whole box quickly when needed.

A Concrete Comparison Using This Blog's Own Data

The Posts table in Azure SQL has a fixed set of columns - Id, Title, Slug, Tech, and so on. Every row shares exactly the same structure. Adding a genuinely new field - say, an array of structured code blocks with language tags - means altering the table schema for every single row, even posts that will never use that field.

The same data reshaped as a Cosmos DB document removes that constraint entirely. One document might carry a codeBlocks array with language and code properties. A different document might instead carry a relatedServices array and a diagramUrl pointing at an image. Neither document needs to match the other's shape, and no schema migration is required to introduce a field that only some documents will ever use.

Core Cosmos DB Concepts

An Account is the top-level Cosmos DB resource - a single account can actually support multiple APIs, including NoSQL, MongoDB, Cassandra, Gremlin, and Table, though the NoSQL API is the most commonly used and the one covered here. A Database is a logical grouping within an account, conceptually similar to a SQL database. A Container is roughly the document-world equivalent of a SQL table, but with no fixed schema enforced across the documents inside it. An Item, or document, is a single JSON object inside a container - roughly equivalent to a row, but with a
flexible shape.

The Partition Key deserves its own emphasis, because it is genuinely the single most consequential design decision in Cosmos DB. It is a property within your document used to distribute data across physical partitions for scale. Choosing poorly does not just create a minor inefficiency - it can cause real performance problems as data grows, because all writes for a given partition key value land on the same physical partition.

Choosing a Partition Key

For a hypothetical Posts container, several candidates illustrate the tradeoff clearly. Partitioning by technology tag works well if queries are usually filtered by technology, but risks creating a disproportionately large "Azure" partition if that tag dominates the content, which becomes a hot, oversized partition relative to the others. Partitioning by slug guarantees excellent distribution since every slug is unique, but querying "all posts" still requires a fan-out across every partition, which costs more in Request Units. Partitioning by year suits time-based access patterns well, but concentrates all of the current year's writes onto a single partition until the calendar turns over.

The actual rule underlying all of this: pick the property that aligns with the most frequent query pattern in your application, while also spreading data roughly evenly across many distinct values.

Querying Cosmos DB

Cosmos DB's NoSQL API uses a query language that visually resembles SQL but operates over JSON structure rather than table columns. Anyone who already knows SQL picks this up quickly. A query like selecting title, slug, and reading time from a container, filtering where a tech array contains "Azure", and ordering by reading time descending, reads almost identically to the equivalent Azure SQL query - the syntax is genuinely that close for simple cases.

Where it diverges meaningfully is querying into nested structures. Cosmos DB can join directly into an array nested inside the same document - for instance, finding every code block with a specific language tag, embedded inside posts - without needing a second table at all. The equivalent in a relational model requires an actual separate table and a real JOIN across tables, since SQL has no native concept of an array living inside a single row.

LINQ Against Cosmos DB

For anyone who has used Entity Framework Core's LINQ support against Azure SQL, querying Cosmos DB from C# will feel immediately familiar at the syntax level - Where, OrderByDescending, and the rest of the standard LINQ vocabulary all work against a Cosmos DB container through its LINQ provider. The vocabulary is the same. The engine underneath is completely different - EF Core generates T-SQL against a relational engine, while Cosmos DB's LINQ provider generates its own SQL-like query against a document store with an entirely different cost and performance model. Familiar syntax does not imply equivalent execution.

Request Units

Cosmos DB does not bill the way Azure SQL does, on compute tiers and DTUs or vCores. It bills on Request Units, a normalized measure of the cost of any given operation. A simple point read by id and partition key is roughly one Request Unit - the cheapest possible operation in the system. A broader query scanning many documents can cost tens or hundreds of Request Units depending on its complexity. Writes typically cost more Request Units than an equivalent read.

Two billing modes exist. Provisioned throughput reserves a fixed Request Unit per second capacity that is paid for whether it is fully used or not - appropriate for predictable, steady traffic. Serverless mode charges only for the Request Units actually consumed, with no fixed reservation at all - a far better fit for unpredictable, generally low-traffic workloads, which describes most personal blogs and small applications far more accurately than a fixed provisioned tier would.

When Cosmos DB Is The Right Choice Over Azure SQL

Cosmos DB earns its place when document shape varies significantly between items, when an application needs single-digit millisecond reads at genuinely global scale, when multi-region write distribution matters, when data is naturally hierarchical or nested in a way that maps cleanly to JSON, or when throughput needs to scale elastically and automatically without manual intervention.

Azure SQL remains the better choice when data is naturally tabular with a consistent shape across records, when strong relational integrity through foreign keys and joins across many related tables genuinely matters, when a team already thinks fluently in SQL and the data fits that model comfortably, or when complex multi-table transactions are a common part of the workload.

This blog's own Posts data is tabular and consistent in shape - Azure SQL remains the correct choice for it. Where Cosmos DB genuinely earns its place, based on real production experience, is somewhere quite different from "replace your application database": holding operational and log data from an integration platform, where one event might carry a handful of fields and another dozens, then querying that data with KQL for troubleshooting and reporting rather than serving it as primary application content. That pattern - flexible storage for fast-changing
operational data, queried for insight rather than served to end users - is worth knowing even for engineers who never touch Cosmos DB as a primary database.

What Azure Blob Storage Actually Is

Azure Blob Storage stores unstructured files - images, videos, PDFs, backups, log files - as objects called blobs, organized inside containers. It functions as neither a traditional database nor a traditional filesystem but remains accessible over HTTP in a way that feels filesystem- like in practice.

If Azure SQL and Cosmos DB are both filing systems built for structured information, Blob Storage is closer to a warehouse. There is no querying the contents of what sits inside a stored box - only knowing which box it is, after which the warehouse hands it over, whole, exactly as it was left.

Blob Storage Tiers

The Hot tier is optimized for frequently accessed data, carrying the highest storage cost paired with the lowest access cost - appropriate for something like images displayed on a blog's homepage that get requested constantly. The Cool tier suits infrequently accessed data intended to be stored for at least thirty days, trading lower storage cost for higher access cost relative to Hot - last month's exported analytics reports fit naturally here. The Archive tier suits data rarely accessed at all, intended for at least one hundred eighty days of storage, with the lowest storage cost and highest access cost of the three, plus the detail that data must be rehydrated before it can be read again, a process that can take hours - genuinely multi-year backups nobody expects to open belong here.

Blob Types

Block Blobs are the most common type, optimized for efficiently uploading large amounts of data in individually manageable blocks - the right choice for images, video, documents, and backups in the overwhelming majority of cases. Append Blobs are optimized specifically for append operations, allowing data to be added to the end without modifying what already exists - well suited to logging scenarios where new entries continuously accumulate. Page Blobs are optimized for random read and write access patterns, primarily relevant to virtual hard disk files backing virtual machines, a scenario that rarely comes up outside infrastructure-focused work.

SAS Tokens

Blob containers are private by default, which is the correct default. A Shared Access Signature, or SAS token, grants temporary, narrowly scoped access to a blob or container without making the entire container public and without sharing the storage account's actual access key. A SAS token can be constrained to a specific blob, a specific permission like read-only, and a specific expiration time - a token built to expire in one hour, granting read-only access to exactly one blob, does exactly that and nothing more once it expires.

Where This Blog Would Realistically Use Blob Storage

A few concrete, realistic use cases stand out for this specific project, none of which are implemented yet. Post cover images and inline diagrams currently rely on external links rather than self-hosted assets - Blob Storage would be the natural home for self-hosted images served from a stable URL. The Open Graph share image used for social previews is currently committed directly into the frontend code repository - it could instead live in Blob Storage behind a CDN, cleanly separating binary assets from application source code. Scheduled database backups, exported independently of Azure SQL's own built-in backup retention, would fit naturally in the Cool tier. And if a comments feature with image uploads is ever added, Blob Storage is precisely the right service for storing user-submitted files.

The Three Services, Side By Side

Azure SQL handles fixed-shape rows, queried in standard SQL, requiring a defined schema, and billed on a DTU or vCore model - the right fit for relational, structured data, which describes this blog's own Posts table accurately. Cosmos DB handles flexible JSON documents, queried in a SQL-like language suited to NoSQL access patterns, requiring no fixed schema, and billed on Request Units - the right fit for fast-changing documents that need global scale. Blob Storage handles raw files with no query language at all beyond retrieval by key, requiring no schema in the traditional sense, and billed per gigabyte stored plus per operation - the right fit for images, video, backups, and any other genuinely unstructured content.

Key Lessons

• Choosing a Cosmos DB partition key is the single decision most likely to cause real performance problems later if made carelessly early on.

• Serverless billing mode fits unpredictable, low-to-moderate traffic far better than provisioned throughput - defaulting to provisioned out of habit, without a real reason, adds cost without a corresponding benefit.

• SAS tokens belong on any blob access that needs to be temporary or narrowly scoped - a fully public container should be reserved for content that is genuinely meant to be public without exception.

• LINQ syntax transfers comfortably between EF Core and Cosmos DB, but the execution engine and cost model underneath are entirely different - familiarity with the syntax should not be mistaken for familiarity with the performance characteristics.

• The actual skill is matching the shape of the data to the right service, not defaulting to whichever tool sounds newest or most powerful. A relational table remains exactly the right choice for plenty of real workloads, including this blog's own. And Cosmos DB's most valuable real-world use is not always "primary database" - operational and log data analysis, queried with KQL, is a pattern worth recognizing on its own.

Summary

Azure SQL fits data that is naturally tabular and relational. Cosmos DB fits data that is naturally document-shaped, fast-changing, or in need of global low-latency distribution. Blob Storage fits anything that is fundamentally a file rather than structured data at all. All three coexist comfortably within real Azure architectures - the genuine skill lies in matching the shape of the data to the right service, rather than selecting one tool and forcing every problem through it regardless of fit.

---

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-cosmos-db-blob-storage

More from TechStack Blog, by category:
Azure: https://www.techstackblog.com/category.html?cat=azure
Database: https://www.techstackblog.com/category.html?cat=database

Follow for weekly posts on Azure, C#, and cloud engineering.