OLTP

← Back to DP-420 Terminology Reference

Category: Core Concepts

Summary: Online Transactional Processing; small, fast operations — Cosmos DB's core transactional workload type.

Overview

OLTP (Online Transactional Processing) refers to workloads characterized by many small, fast, individual reads/writes/updates — such as processing an order or updating a user profile — as opposed to OLAP(Online Analytical Processing), which runs large aggregations and analytical queries over historical data. Azure Cosmos DB for NoSQL is purpose-built as an OLTP database, optimized for low-latency point operations and high-throughput transactional workloads; analytical workloads are instead handled by pairing it with the analytical store via Azure Synapse Link, keeping OLTP performance isolated from analytical/reporting queries.

Microsoft now recommends Azure Cosmos DB Mirroring in Microsoft Fabric, which provides the same zero-ETL pattern and deeper Fabric integration

| Technology                  | Reads From           |
| --------------------------- | -------------------- |
| Cosmos SDK                  | Transactional Store  |
| Change Feed Processor       | Transactional Store  |
| Synapse Spark               | Analytical Store     |
| Synapse Serverless SQL Pool | Analytical Store     |
| Fabric Mirroring            | OneLake Delta Tables |

/-----------------------------------------------------------------------------------\
| Requirement                      | Use Serverless SQL Pool | Use Fabric Mirroring |
| -------------------------------- | ----------------------- | -------------------- |
| Existing Synapse environment     | ✅                     | Possible              |
| Need T-SQL directly on Cosmos DB | ✅                     | ❌                   |
| New greenfield analytics project | ❌                     | ✅                   |
| Power BI in Fabric               | ❌                     | ✅                   |
| OneLake integration              | ❌                     | ✅                   |
| Lakehouse architecture           | ❌                     | ✅                   |
| Legacy DP-420 question           | ✅                     | Sometimes             |
| Future Microsoft direction       | ❌                     | ✅                   |
\===================================================================================/


| Scenario                                          | Recommended Technology                  | Data Source                      | Query Engine                             | Impact on OLTP             |
| ------------------------------------------------- | --------------------------------------- | -------------------------------- | ---------------------------------------- | -------------------------- |
| Transaction processing (application reads/writes) | Azure Cosmos DB for NoSQL               | Transactional store (OLTP)       | Cosmos DB SDK / SQL API                  | Designed for this workload |
| Near real-time analytics (legacy approach)        | Azure Synapse Link + Analytical Store   | Analytical store                 | Synapse Spark or Serverless SQL Pool     | No impact on OLTP          |
| New analytics projects                            | Cosmos DB Mirroring in Microsoft Fabric | Mirrored Delta tables in OneLake | SQL Endpoint, Lakehouse, Spark, Power BI | No impact on OLTP          |
| Reporting & BI in Fabric                          | Cosmos DB Mirroring                     | OneLake                          | Power BI, SQL Analytics Endpoint         | No impact on OLTP          |
| Ad-hoc T-SQL against Cosmos DB without data copy  | Synapse Serverless SQL Pool             | Cosmos DB Analytical Store       | OPENROWSET / T-SQL                       | No impact on OLTP          |

More Info & Links

• Microsoft Learn: Analytical store overview

DP-420 Style Practice Questions

Q1. What best describes an OLTP workload?

• A. Many small, low-latency transactional operations such as inserts, updates, and point reads
• B. Large batch aggregations run periodically over historical data
• C. A single large data warehouse query joining many tables
• D. A one-time bulk data migration job

Q2. How does Azure Cosmos DB avoid impacting OLTP performance when running analytical queries?

• A. By maintaining a separate analytical store (via Azure Synapse Link) so analytical queries don't consume transactional RUs
• B. By throttling all OLTP writes during analytical queries
• C. By requiring OLTP and analytical workloads to share the same index
• D. By disabling the change feed during analytics

Answer Key

Answers are listed at the very end so you can attempt the questions first.

• Q1 (OLTP): A. Many small, low-latency transactional operations such as inserts, updates, and point reads — OLTP workloads consist of frequent, small, fast transactional operations, which is what Azure Cosmos DB's transactional store is optimized for.
• Q2 (OLTP): A. By maintaining a separate analytical store (via Azure Synapse Link) so analytical queries don't consume transactional RUs — The analytical store is a separate, column-oriented copy of the data, so OLAP/analytical queries don't compete with OLTP workloads for RUs.

---

DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page