Building AI-Scale Demand Planning on Azure Cosmos DB: A Retail Story

Demand planning sounds straightforward until you're staring at billions of rows of historical sales data, dozens of planners making concurrent adjustments, and a legacy BI tool that grinds to a halt every time someone tries to drill into store-level forecasts. At that point, it stops being a planning problem and becomes an infrastructure problem, and the database you choose determines whether your platform scales or struggles.

This is the story of how Tredence partnered with a leading grocery retail chain to rebuild their corporate demand planning platform from the ground up, with Azure Cosmos DB at the core.

The Problem: A BI Tool Holding Back a Planning Team

The client's existing demand planning workflow had outgrown its tooling. Planners were working against a system built for a different era of data volumes, one that couldn't keep pace with the scale, granularity, or interactivity the business now demanded:

• Massive data volumes: hundreds of millions of store-item SKU forecast records to query and serve in near real time
• No bulk adjustment capability: planners were editing forecasts item by item, burning hours on work that should take minutes
• Poor granularity: comparing forecasts at the DFU (Demand Forecast Unit; store/item) level was slow, clunky, and error-prone
• No ML integration: recommendations and exceptions were entirely manual, with no automated signals to guide planners toward high-risk items first

The business needed a purpose-built web application: something fast, planners-first, and capable of handling enterprise-scale data without sacrificing the responsiveness that makes a tool usable day to day.

Why Azure Cosmos DB and Why It Was the Right Call

When Tredence's architecture team evaluated the data layer, three requirements immediately ruled out relational databases and traditional BI stores:

1. Millisecond read/write latency at scale: planners need sub-second responses when filtering, adjusting, and reviewing forecasts across hundreds of millions of records
2. Dynamic, schema-flexible data: forecast structures, exception types, and adjustment metadata evolve constantly; a rigid schema would slow down the product
3. Low operational overhead: the team needed a fully managed service that could autoscale without DBA-intensive tuning

Azure Cosmos DB cleared all three. Specifically, the NoSQL API with a consolidated schema per store-item SKU combination gave the team a single, high-performance document per planning unit, eliminating costly joins while keeping reads predictably fast regardless of query pattern.

The result: millisecond-level read and write latencies, consistently, across the full dataset.

The Architecture: Fully Azure, Built to Scale

Rather than reaching for a multi-cloud or third-party stack, the team built entirely within the Azure ecosystem, giving the client a unified security perimeter, consistent governance, and a single vendor relationship to manage.

Core stack:

How the Data Flows:

The Cosmos DB instance sits at the heart of the live application experience. When a planner logs in, their workload, assigned items, and current forecast state are served directly from Cosmos DB, fast enough that filtering and drilling down feels instantaneous. When a planner submits a bulk adjustment, it writes back to Cosmos DB and triggers a change feed event that propagates updates downstream to the forecasting engine and Azure Data Explorer for historical tracking.

Azure Data Explorer handles the heavy analytical side, querying years of historical sales data for trend comparisons and accuracy reporting while Cosmos DB handles everything the planner touches directly. Each layer does what it's best at.

What Cosmos DB Unlocked for the Planning Team

Choosing Cosmos DB as the primary operational store wasn't just an infrastructure decision; it directly shaped what the product could deliver to planners:

• Bulk Forecast Adjustment at Scale: By consolidating forecast data into a single document per SKU-store combination, the platform can push bulk adjustments across thousands of items in a single operation, with Cosmos DB's change feed propagating those changes downstream automatically. What used to take planners hours now takes minutes.
• Personalized, Role-Based Workload Views: Each planner's session state, assigned items, review progress, and preferences are stored and served from Cosmos DB, enabling a personalized "to-do list" experience that filters hundreds of millions of data points into exactly what that planner needs to act on today.
• Two ML-Powered Exception Surfacing: Two models, an adjustment recommendation model and an exception identification model, write their outputs into Cosmos DB alongside the forecast data. Planners see ML signals directly in their workflow, with no ETL delay between model scoring and UI display.
• Real-Time Workload Visibility for Managers: Team dashboard metrics (review rates, ML recommendation acceptance, planner performance KPIs) are computed and served from Cosmos DB, giving managers a live view of team productivity without any separate reporting pipeline.

Cosmos DB Capabilities That Made the Difference

This engagement reinforced what we've seen across our Cosmos DB practice:

Single-digit millisecond latency isn't a marketing claim; it's what allows a demand planning UI to feel responsive when a planner is working through thousands of SKUs under time pressure.

Schema flexibility meant the team could iterate on the data model, adding new exception types, adjustment metadata fields, and ML score attributes without migration ceremonies slowing down the product roadmap.

Autoscale throughput meant the platform could absorb Monday-morning planning peaks (when the whole team logs in simultaneously after the weekend) without over-provisioning for the rest of the week.

Change feed was the architectural enabler for keeping the forecasting engine, ADX historical store, and UI all in sync without building bespoke event plumbing.

99.999% availability SLA gave the client confidence that their planning workflow, which runs on a strict weekly cadence, would be well protected against missed cycles due to database downtime.

The Outcomes

The rebuilt platform delivered measurable impact across the planning organization:

• 25-40% reduction in manual review time, freeing planners to focus on strategic decisions rather than mechanical adjustments
• 5-10% uplift in forecast accuracy, driven by ML-surfaced recommendations and faster exception resolution
• 10-15% improvement in resource allocation, as managers gained real-time visibility into planner workload and performance
• Scalable throughput to support the full planning team reviewing hundreds of millions of forecast units on a weekly cadence

The Broader Pattern: Cosmos DB as the AI-Scale Operational Layer

What this engagement illustrates isn't unique to demand planning. We're seeing the same architecture pattern where Cosmos DB shows up as the low-latency, flexible, event-driven operational layer across AI-powered applications:

• In enterprise GenAI assistants, where Cosmos DB holds conversational memory, telemetry, and synchronized HR datasets to power always-on, context-aware AI experiences
• In offer management platforms, where millions of dynamic, case-specific offers are created and published at sub-second latency, with Cosmos DB handling both the write throughput and the real-time read serving

The common thread is that AI-scale applications need two things from their database: the ability to serve users fast enough that the AI feels responsive, and the flexibility to evolve the data model as fast as the product evolves. Cosmos DB delivers both, and when paired with the rest of the Azure ecosystem, it becomes the operational backbone that lets everything else run at scale.

Tredence's Azure practice has deep hands-on experience designing, building, and optimizing Cosmos DB deployments across retail, CPG, and enterprise AI use cases. If you're evaluating Cosmos DB for a new platform or looking to optimize an existing deployment, we'd be glad to talk.