Azure Architecture Guide

Choosing Data Services

What This Chapter Is About

Help readers choose Azure data services from data shape, access pattern, consistency, scale, lifecycle, and operating needs.

This chapter explains why the right data service follows the workload's data model and query behavior, not only a familiar database name. The focus is not to memorize every database and storage feature. The focus is to understand which data responsibility each service is designed to carry.

Keep one durable idea in view:

Data service selection starts with how the application stores, queries, protects, scales, and retains the data.

Sections

  1. Data Selection Mental Model

  2. Relational Data with Azure SQL

  3. Document Data with Azure Cosmos DB

  4. Object, File, and Durable Storage

  5. Scale, Consistency, and Cost Trade-Offs

  6. Data Choice Scenario

How the Chapter Develops

The chapter develops in this order:

  1. Start from the architecture question: what shape is the data and how will the workload use it?

  2. Explain relational data and Azure SQL as a fit for structured records, SQL queries, and transactions.

  3. Explain document data and Cosmos DB as a fit for selected non-relational and globally distributed access patterns.

  4. Explain object and file storage as different storage responsibilities, not interchangeable buckets of bytes.

  5. Compare scale, consistency, lifecycle, backup, security, and cost trade-offs.

  6. Apply the model to a commerce platform with several different data responsibilities.

Together, these sections show that data design begins with application behavior, not database fashion.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

  • Distinguish relational, document, object, and file data responsibilities.

  • Explain when Azure SQL fits a workload.

  • Explain when Azure Cosmos DB fits a workload.

  • Explain when Azure Blob Storage or Azure Files fits a workload.

  • Connect data service choices to query patterns, consistency, scale, lifecycle, security, and cost.

  • Sketch a mixed data architecture where each store has a clear job.

Key Ideas

  • Azure SQL fits relational data, transactions, and SQL query patterns.

  • Cosmos DB fits document-style or globally distributed access patterns when partitioning and cost are understood.

  • Blob Storage fits object data, static content, backups, logs, and data lake patterns.

  • Azure Files fits shared file semantics, not general object storage.

  • Data service selection should follow query patterns and lifecycle, not only storage capacity.

  • One architecture may use several data services for different responsibilities.