Choosing the Right Azure Storage Service

The seven storage services at a glance

Blob Storage: unstructured objects at scale

Use Blob Storage when you are storing and serving files where the content is opaque to the storage layer — images, videos, PDFs, audio files, application backups, log archives, and static website assets. Blob Storage scales to petabytes with no configuration and serves files over HTTP/HTTPS directly from the storage endpoint.

Example: storing product images for an e-commerce site. Product images are uploaded by sellers, stored in Blob containers organized by product ID, and served via CDN URLs. The application stores only the blob name in the relational database, not the image bytes. Lifecycle management policies move images for discontinued products to the Cool or Archive tier automatically to reduce costs.

Blob Storage is not the right choice when you need to query the file content (full-text search, SQL queries), manage structured metadata alongside files, or serve files at sub-millisecond latency from an application’s local filesystem.

Azure Files: shared file systems for VMs and containers

Use Azure Files when you need a network file share that multiple VMs or containers can mount simultaneously using SMB (Windows, Linux) or NFS (Linux). It is particularly useful for lift-and-shift migrations where an on-premises application reads configuration from a network share, or for Kubernetes workloads that need a ReadWriteMany persistent volume.

Example: shared configuration files across multiple App Service instances or VMs. A legacy application reads its configuration from \fileserver\config\app.ini. In Azure, you create an Azure Files share, mount it on each VM, and point the application at the same path. No code change required.

Azure Files has throughput and IOPS limits that make it unsuitable for database files (SQL Server data files on Azure Files will be slow) or high-frequency small-file access (each file operation has network latency). For database workloads, use Azure Managed Disks. For analytics, use Blob Storage or ADLS Gen2.

Azure Queues: lightweight async messaging

Use Azure Queues (part of Azure Storage) for simple first-in-first-out message queuing between application components. A producer writes messages and a consumer polls the queue, processes messages, and deletes them. Messages are held for up to 7 days and can be up to 64 KB in size.

Example: order processing pipeline. A web application accepts an order, writes the order ID to a Storage Queue, and returns a response to the user immediately. A background Azure Function polls the queue, processes the order (inventory check, payment, fulfillment), and deletes the message when complete. The web application and the processing function are fully decoupled — if processing is slow, messages queue up without affecting the user experience.

Use Azure Service Bus instead of Storage Queues when you need dead-letter queues, ordered delivery, message sessions, pub/sub topics, or messages larger than 64 KB. Storage Queues are the simple, low-cost option; Service Bus adds reliability features at higher cost.

Cosmos DB: global-scale NoSQL

Use Cosmos DB when your data is document-shaped, the schema evolves frequently, you need multiple global write regions, or you need sustained very high throughput (tens of thousands of operations per second). Cosmos DB also excels at session state, user profiles, product catalogs, gaming leaderboards, and any workload where you look up data by a single key.

Example: user session state for a global SaaS application. Users from Europe, Asia, and North America all expect fast responses. Cosmos DB with multi-region writes stores session data in the region closest to each user. Read and write latency is under 10ms in each region. The schema is flexible — different sessions can have different fields. TTL automatically expires sessions after 24 hours of inactivity.

Cosmos DB is not the right choice for complex analytical queries that join data across multiple collections, reporting workloads that aggregate across millions of records on non-partition-key fields, or applications that have many-to-many relational constraints enforced at the database level. For those, use Azure SQL.

ADLS Gen2: the analytics data lake

Use ADLS Gen2 as the storage layer for big data analytics, machine learning feature stores, and data warehouse landing zones. It integrates natively with Azure Synapse Analytics, Azure Databricks, Azure Data Factory, and HDInsight. The hierarchical namespace enables data lake zoning (raw/cleansed/curated) with per-directory ACL controls for different teams.

Example: enterprise data lake for reporting and ML. Data from CRM, ERP, and web analytics lands in the raw zone as JSON and CSV files via Data Factory pipelines. A Synapse Spark pool reads the raw data, validates and enriches it, and writes Parquet files to the cleansed zone. Data science teams read from the curated zone using Databricks notebooks. ADLS Gen2 ACLs give each team read/write access only to their own zone.

ADLS Gen2 is not suitable for transactional reads and writes (it has no row-level locking, no ACID transactions), low-latency random access to small files, or serving content over HTTP to end users (use Blob Storage with CDN for that).

Azure SQL Database: relational data with managed infrastructure

Use Azure SQL Database when your data is relational — multiple tables with foreign key relationships, complex queries with multi-table JOINs, or application logic that depends on ACID transactions across multiple rows or tables. It runs SQL Server on fully managed infrastructure with automatic backups, patching, and high availability.

Example: order management system for a retail application. Orders, customers, products, inventory, and shipping records all have relationships. A single order creation transaction inserts a row in the orders table, updates inventory, and creates a shipping record — all atomically. Reporting queries join orders with customers and products to calculate revenue by category. Azure SQL handles all of this natively with standard SQL.

Azure SQL has limits at the high end: a single database scales to 4 TB of storage and thousands of IOPS, but it is a single-instance model (not horizontally sharded). For write workloads that exceed what a single SQL instance can handle, consider sharding with Elastic Database Pools, or rearchitecting with Cosmos DB for the write-heavy entities.

Quick-decision checklist

Work through these questions to narrow down the right service:

• Are you storing files (images, PDFs, videos, binaries)? → Blob Storage. If multiple VMs need to mount it as a drive → Azure Files.
• Do you need to decouple components asynchronously? → Azure Queues (simple) or Azure Service Bus (advanced).
• Is your data relational with JOINs, foreign keys, and complex queries? → Azure SQL Database (or PostgreSQL/MySQL Flexible Server for open-source engines).
• Is your data JSON documents with a flexible or evolving schema? → Cosmos DB.
• Do you need global multi-region writes? → Cosmos DB (only Azure NoSQL option with multi-master writes).
• Are you building an analytics pipeline or data lake? → ADLS Gen2 as the storage layer, with Synapse or Databricks for compute.
• Do you need a simple key-value store at very low cost? → Azure Table Storage (or Cosmos DB Table API if you want better performance).
• Is cost the primary constraint and data volume is very high? → Blob Storage (cheapest per-GB) or ADLS Gen2 with lifecycle tiering to Cool/Archive.

Cost comparison guidance

Storage costs vary widely across services. These are approximate figures for the East US region to give order-of-magnitude comparisons:

The biggest cost trap is mismatching the service to the workload. A Cosmos DB container provisioned at 10,000 RU/s costs around $60/day whether or not you use those RUs. A Blob Storage account holding 1 TB costs roughly $18/month. Put binary files in Blob Storage, not Cosmos DB documents.