Azure SQL or Cosmos DB for a Business Application?

Relational integrity, transactions, joins, document shape, distribution, and query behavior matter more than a product label. Write the most important reads and writes first, then prototype their behavior and cost. Some systems use more than one data store, but that adds synchronization work.

Model the invariants

If an order, payment, and inventory reservation must change together, express that consistency need explicitly. If records vary by type and are read by partition, express that pattern too.

Test queries, not slogans

Create representative data and run the queries the product actually needs: customer history, reports, status changes, search, and operational dashboards.

Plan lifecycle

Check schema evolution, backups, retention, region needs, operational skills, and cost under realistic traffic. A cheap demonstration dataset can hide the expensive production pattern.

Write data invariants before selecting storage

List the records that must change together, uniqueness rules, query shapes, expected volume, and retention needs. An order with lines and payments may demand relational constraints and reporting joins; an independent event stream may have a different partition and access pattern. Model a handful of real reads and writes with representative data, including a correction and a concurrent update. If the design proposes both stores, say which one owns each fact and how a failed projection is repaired. This avoids trading a familiar database question for an unplanned synchronization problem.

A storage worksheet should contain the five most important writes and reads, expected record size, relationship or partition key, consistency need, growth pattern, and recovery method. Include a multi-record update and a report that crosses customer or time boundaries. Prototype those operations with representative data rather than empty tables. Record response time and cost assumptions next to correctness results, and note which indexes or data duplication the design requires. If two stores are proposed, add the authoritative copy and reconciliation path for every shared fact. This worksheet makes the decision explainable to both application engineers and the people who own business data.

Test cost and recovery with production-like behavior

A tiny sample can hide the effect of hot partitions, cross-partition queries, indexes, transactions, or frequent reports. Measure the hardest queries under realistic data distribution and write rate. Review backup, restore, region behavior, security, and operational tooling with the people who will support the system. Estimate cost from those measurements and expected growth rather than a brochure example. Document the migration or export route if access patterns change. The choice should preserve correctness and explainability first; performance and cost are then evaluated against the actual workload.

Decision checklist

• Write five critical read and write operations.
• Identify transaction boundaries and uniqueness rules.
• Prototype the hardest query.
• Estimate cost and recovery with representative data volume.

A small test before committing

Create a compact dataset with the relationships and volume the business expects. Implement five critical operations, including the hardest update and the most important report, against each plausible store. Measure correctness, query complexity, latency under representative load, and estimated production cost. Include a recovery test. The choice may be obvious when a transaction must preserve several related records, or when an independent event stream dominates; test the actual invariants rather than the label.

Worked scenario

A hypothetical service app with invoices and related line items may benefit from relational constraints. A high-volume stream of independent device events may favor a document-oriented ingestion pattern. The same company could use both, with a deliberate reconciliation boundary.

Further reading: official source for this topic.

For a scoped application of this decision, see Azure Cloud Platforms.