Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
155065 stories
·
33 followers

Microsoft’s new Surface RTX Spark Dev Box is like the cheese grater Mac Pro, and that’s why I love it

1 Share

Microsoft just announced the Surface RTX Spark Dev Box at Build 2026, and for the first time in years, a Surface device made me stop scrolling my X feed for all the Build 2026 news and stare at the quirky design.

The compact AI-focused desktop is designed for developers building local AI workloads, fine-tuning models, running agentic workflows, and experimenting with on-device inference without constantly depending on cloud compute. Microsoft says the system delivers up to one petaflop of AI compute using NVIDIA’s RTX Spark superchip with 128GB of unified memory.

But the specifications aren’t what intrigues me.

Surface RTX Spark Dev Box looking like a grill
Image: Microsoft

The Surface RTX Spark Dev Box looks bizarre in the best possible way. Microsoft built the machine using a monolithic aluminum chassis covered in roughly 1,000 ventilation holes, which functions as both the thermal system and the visual identity of the product. Microsoft references the “1,000 teraflops” of compute performance as the inspiration behind the number of holes in the industrial grille design.

And yes, it absolutely reminds me of Apple’s infamous “cheese grater” Mac Pro design from 2019. Except here, the holes actually feel more purposeful because this thing genuinely needs cooling for sustained AI workloads.

Cheese grater design of Mac Pro 2019
Cheese grater design of Mac Pro 2019

Surface has been missing this kind of hardware personality for a long time.

After Panos Panay left Microsoft, the Surface lineup slowly shifted into making safer, more mainstream hardware. Recent Surface Laptop and Surface Pro generations have been premium and polished, but they are in no way outstanding when compared to other premium Windows PCs from the likes of Dell and Lenovo. Sadly, Surface stopped feeling experimental.

But I’m delighted to see the Surface RTX Spark Dev Box change that notion.

Surface RTX Spark Dev Box on a white platform

Of course, the performance claims need to be treated carefully until real-world benchmarks arrive. However, seeing Microsoft build something unapologetically niche and visually aggressive feels refreshing.

Specifications of the Surface RTX Spark Dev Box

Specification Details
Processor (CPU) NVIDIA Grace CPU (Up to 20 Arm-based cores)
Graphics (GPU) NVIDIA Blackwell RTX GPU (6,144 CUDA cores)
System Platform NVIDIA RTX Spark Superchip
Memory (RAM) 128GB Unified Memory (Dynamically shared between CPU and GPU)
AI Compute Performance Up to 1 Petaflop (Capable of running 120-billion parameter models locally)
Thermal & Power 100W sustained thermal envelope
Chassis & Cooling Compact aluminum housing acting as a heatsink with a ~1,000-hole ventilation grille
Ports & Connectivity 2x USB Type-C, 2x USB Type-A, 1x HDMI, 1x Ethernet (RJ45), 1x 3.5mm headphone jack
Operating System Windows 11 Pro (Developer-optimized image)
Pre-configured Software Visual Studio Code, GitHub Copilot, WSL 2, PowerShell 7, Git, Python, Node.js, native CUDA support

 

Ports in Surface RTX Spark Dev Box
Ports in Surface RTX Spark Dev Box

Surface RTX Spark Dev Box is built entirely around local AI development

Microsoft says the new Dev Box ships with a developer-optimized version of Windows 11 Pro configured specifically for AI workloads.

According to the official Surface documentation, developers will be able to start coding “on day one” because Microsoft preconfigures the system with Visual Studio Code, GitHub Copilot in Windows Terminal, WSL, PowerShell 7, Git, Python, Node.js, GPU passthrough, CUDA support, and multiple developer-focused settings already enabled.

Even Windows 11 is modified around developer workflows.

Surface RTX Spark Dev Box shots

Dark mode is enabled by default. Widgets are removed. Do Not Disturb is enabled. PowerShell 7 becomes the default shell. Microsoft says the entire idea is to eliminate the hurdles of setting up so developers can begin working immediately after first sign-in.

Surface RTX Spark Dev Box doing tasks

Most AI developers today spend hours configuring environments, debugging dependencies, fixing paths in Python, setting up CUDA drivers, installing WSL packages, and dealing with all the headaches in the container before even touching a model.
Microsoft appears to be trying to turn Windows into a ready-made AI workstation instead of just an operating system.

Surface RTX Spark Dev Box in action

At the center of the system is NVIDIA’s RTX Spark superchip, combining a Grace CPU and Blackwell RTX GPU into one package. Microsoft claims the machine can run AI models with over 120 billion parameters locally using up to 128GB of unified memory. The company also says the system supports local inference with one million token context windows and enough sustained compute to fine-tune models that previously required expensive cloud GPU instances.

NVIDIA RTX Spark dual-die architecture

Again, all of that sounds incredibly ambitious. No independent performance numbers exist yet, and people should absolutely remember what happened with Microsoft’s earlier Snapdragon-powered Windows Dev Kit 2023.

Snapdragon Dev Kit

Microsoft heavily promoted the Qualcomm developer system before quietly cancelling it later. Surface RTX Spark Dev Box is still awaiting FCC approval, too, so some caution is warranted here.

Still, from a design and positioning standpoint, Microsoft clearly understands where AI development is heading. Cloud AI costs are becoming absurdly expensive. Developers are looking for hybrid workflows where smaller models, inference tasks, and experimentation happen locally while larger workloads move to the cloud only when necessary.

Microsoft repeatedly used the phrase “unmetered intelligence” during Build 2026. The idea is that local AI compute reduces token costs, lowers cloud dependency, and allows developers to iterate faster. The Dev Box looks like a product designed by people who understand those workflows.

Surface RTX Spark Dev Box with monitors and keyboard and mouse

The duality between the Surface RTX Spark Dev Box and the Surface Laptop Ultra

The Surface Laptop Ultra looks fantastic. In many ways, it feels like Microsoft’s answer to the MacBook Pro, and while the inspiration is obvious, I honestly think Microsoft’s version looks cleaner and more refined. The hardware design is premium, modern, and distinctly Surface, even if it still follows the familiar high-end MacBook-ish formula.

Surface Laptop Ultra
Surface Laptop Ultra. Image Credit: Microsoft

But then you look at the RTX Spark Dev Box, and it feels like it came from an entirely different era of Microsoft hardware design philosophy.

One product is polished, mainstream, and commercially safe. The other is aggressively niche, covered in ventilation holes, and unapologetically weird, which is understandable as it is positioned for devs.

But while the Surface Laptop Ultra may be the more practical product, the Dev Box is the one that reminds me of the era when Surface hardware constantly experimented with unusual ideas, strange form factors, and ambitious industrial design.

That’s the version of Surface I’ve missed the most.

The best-designed Surface devices showed Microsoft at its most ambitious

Microsoft built the Surface brand around hardware experiments that were years ahead of the rest of the PC industry. Some products succeeded commercially, while others struggled because Windows or Intel hardware was not fully ready for the ideas Microsoft wanted to push.

Even so, it’s the designs and the ideas from the Surface line that made the PC industry interesting as opposed to the mainstream Windows PC and MacBook Pros that have grown to be boring with every passing year. A Surface inspires you to do greater things, at least, that’s what I felt years ago.

Surface Pro (2013)

Back in 2013, the original Surface Pro completely changed how I thought about Windows hardware. A full PC inside a tablet with a kickstand and detachable keyboard sounded impractical at the time, yet Microsoft somehow made the concept feel usable for everyday work.

Surface Pro 2013

The integrated kickstand became one of the defining Surface design elements, and nearly every Windows tablet manufacturer eventually copied some version of it.

Surface Pro X (2019)

Surface Pro X pushed the Surface aesthetic even further with ultra-thin bezels, ARM hardware, LTE connectivity, and magnetic Slim Pen storage built directly into the keyboard. The device looked futuristic long before Windows on ARM matured enough to support the experience properly.

Surface Pro X with Pen

Even today, Surface Pro X still looks more modern than many current Windows laptops.

Surface Laptop (2017)

The original Surface Laptop deserves far more credit than it usually receives. Alcantara keyboards sounded like a terrible idea on paper, but the device looked clean and premium compared to the endless wave of generic aluminum laptops available at the time (even MacBooks).

Surface Laptop 2017

Microsoft managed to make Surface Laptop feel warm and distinctive instead of cold and industrial.

Surface Laptop Go (2020)

Surface Laptop Go took that same design language and compressed it into a smaller, more affordable machine. Compact premium laptops barely existed in the Windows ecosystem back then, and Microsoft somehow made an entry-level Surface device feel desirable (just like what the MacBook Neo did 6 years later).

Surface Laptop Go 2020

Surface Book (2015)

Surface Book is one of the wildest laptop designs Microsoft has ever shipped.

Surface Book folded

The fulcrum hinge looked unlike anything else on the market, while the detachable display transformed into a standalone tablet with the GPU housed inside the keyboard base. Closing the laptop left a visible gap between the display and keyboard, which admittedly looked strange, but the engineering ambition behind the product was impossible to ignore.

Surface Book detached

Surface Laptop Studio (2021)

Surface Laptop Studio carried that same experimental energy forward with its floating pull-forward display mechanism. The screen could transition between laptop, stage, and tablet modes in a way that still feels unique today. I still remember how my eyes glimmered when I watched Panos Panay’s legendary presentation on my normal laptop, wishing to buy it in a couple of years, but it never received an update!

Surface Laptop Studio touch screen

I haven’t ever gotten a similar feeling since then, and I watch keynotes of all major device launches. Microsoft clearly wanted to rethink how creative professionals interacted with Windows hardware instead of simply building another premium notebook.

Surface Studio (2016)

Surface Studio remains my favorite Surface product Microsoft has ever created.

surface studio

The introduction video alone still stands out years later because Microsoft transformed a giant all-in-one PC into a drafting table using a gravity-defying hinge system. Combined with Surface Dial support, the entire experience felt completely different from anything Apple or other PC makers were attempting at the time (and even now).

Microsoft should seriously consider reviving Surface Studio using RTX Spark hardware because architects, designers, creators, and AI developers would probably love a modern Studio built around local AI compute.

Surface Duo (2020)

Surface Duo deserves recognition because, despite the software problems, the hardware itself was beautiful. I still prefer the dual-screen approach over many modern foldables because Surface Duo felt thin, elegant, and mechanically satisfying in a way most foldables still struggle to achieve.

Surface Duo 2020

The hinge engineering alone made the device feel special. Also, I feel the original version looked better than the Duo 2.

Surface Neo (2019)

Surface Neo was another Surface product I genuinely wanted to exist. Modern, efficient chips from Qualcomm, Intel Lunar Lake, or Panther Lake could finally make that form factor practical today.

Surface Neo

Microsoft may have cancelled Neo too early. Well, now another company has made the “Neo” name ubiquitous.

Surface Hub 2 (2018)

Surface Hub was equally ambitious because giant collaborative displays running Windows always felt incredibly “Microsoft.” The product line represented Microsoft’s vision for workplace collaboration long before hybrid work became mainstream.

Surface Hub 2 2018

I still think killing Surface Hub was a mistake.

Surface lost its identity for a while

Older Surface devices always tried to reinvent what PCs could look like. Some ideas failed. Some were impractical. Some launched before Windows itself was ready for the hardware.

But at least Microsoft was trying.

Windows and Intel processors were usually the limiting factors. Battery life was poor. Performance consistency struggled. Touch-first experiences were okay-ish. Many of those ambitious form factors arrived before the software ecosystem could properly support them.

Ironically, modern ARM chips, better efficiency, stronger GPUs, local AI processing, and Microsoft’s renewed focus on native Windows performance might finally make some of those old Surface ideas viable again.

Surface RTX Spark Dev Box feels like the first sign of Microsoft rediscovering that confidence. And even if the product itself ends up being niche, I hope Microsoft keeps going down this path again. Because boring laptops are everywhere.

The post Microsoft’s new Surface RTX Spark Dev Box is like the cheese grater Mac Pro, and that’s why I love it appeared first on Windows Latest

Read the whole story
alvinashcraft
12 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Microsoft Foundry + Agent 365: Microsoft Build 2026

1 Share
From: Microsoft Developer
Duration: 5:28
Views: 36

Amanda Foster demonstrates how to integrate your agents into you business and govern them at scale using Microsoft Foundry at Microsoft Build 2026.

Read the whole story
alvinashcraft
13 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

The Terminal Live - Day 2 at Microsoft Build

1 Share
From: Windows Developer
Duration: 1:44:37
Views: 195

Join the team behind GitHub Copilot as we code live from Microsoft Build & explore the latest in agentic development with GitHub Copilot!

Agenda (Pacific):
- 9:00AM - Windows Terminal with Kayla Cinnamon
- 10:45AM - All things GitHub Copilot CLI with Evan Boyle
- 12:30 PM - Aspire, Copilot, & More, with Maddy Montaquila and Damian Edwards
- 2:15PM - Building with GitHub Copilot SDK with Patrick Nikoletich
- 3:45 PM - Everything VS Code & Agents with Pierce Boggan and Osvaldo Ortego

Links:
GitHub Copilot: https://gh.io/ghcopilot-features
GitHub Copilot CLI Get Started: https://gh.io/copilotcli-quickstart
VS Code: https://gh.io/vscode-copilot-docs
Visual Studio: https://gh.io/vs-copilot-docs
Learn GitHub Copilot CLI: https://gh.io/build-with-copilot-cli
GitHub Copilot App: https://gh.io/about-ghcp-app

Read the whole story
alvinashcraft
14 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Azure Event Grid: Powering IoT and Event-Driven Applications at Scale

1 Share

Modern IoT and event-driven applications demand more than reliable messaging. They require the ability to handle larger payloads, efficiently route data at scale, and automatically adapt to changing workloads. Today, we're excited to introduce a new set of capabilities in Azure Event Grid Namespace (MQTT Broker & Event Broker) that help organizations build more scalable, resilient, and cost-efficient connected solutions. With support for MQTT v5 Subscription Identifiers, larger messages(1MB), and Auto scale-up and scale-down, customers can simplify architecture, reduce operational overhead, and accelerate deployments across manufacturing, automotive, retail, energy, and other connected industries.

Event Grid Standard: MQTT v5 Subscription Identifier (GA)

What it solves

In many MQTT applications, one client subscribes to several topics at the same time. When a message arrives, the application needs a quick way to tell which subscription triggered it and what should happen next.

  • Which subscription triggered this message?
  • Which business rule should process it?

What’s new

MQTT v5 Subscription Identifier is now generally available in Event Grid MQTT broker. Each subscription can have an ID, and that ID is included when the message is delivered.

Each subscription can have an ID, and when a message is delivered, that ID comes with it.

Why it matters

  • Faster message routing
  • Cleaner application logic
  • No need to parse topic strings

Simple example

Example subscriptions:

Subscription ID 101 = factory/line1/temperature

Subscription ID 202 = factory/line1/vibration

When a message arrives

If the message comes in with Subscription ID 101, the app immediately knows it is temperature data and can send it to the correct processing path without inspecting the topic string.

Instant message context with MQTT v5 Subscription Identifiers

Common use cases

  • Manufacturing lines with hundreds of sensors
  • Automotive telemetry platforms
  • Multi‑tenant IoT solutions
  • Rule engines and stream processors

Event Grid Standard: 1MB Message Support (GA) - Coming Soon

Applies to both MQTT and non-MQTT workloads.

What it solves

As devices and applications become more capable, the events they send are becoming richer too.

In many real-world scenarios, a single message may need to include things like:

  • Sensor batches
  • Telemetry snapshots
  • Diagnostics data
  • Configuration payloads

Before this, customers often had to split large messages into smaller pieces or store the payload somewhere else and send only a reference.

What’s new

Event Grid Standard Namespace now supports larger event payloads upto 1MB for both MQTT and non-MQTT scenarios. That means customers can send more complete information in one message and reduce complex workarounds in design.

Why it matters

  • Fewer architectural components
  • Simpler producers and consumers
  • Lower latency for real‑time decisions

Example

Before: A factory device sent the main payload to storage and then published a small event that pointed to that file.

Now: The same device can publish the full event payload directly through Event Grid, making the flow easier to build and easier to operate.

Example: A smart machine can send a larger diagnostic package in one event, including the machine ID, a batch of readings, and a timestamp, instead of splitting the information across multiple services.

 

Unlock larger event-driven workloads with Azure Event Grid

Common use cases

  • Smart manufacturing telemetry
  • Vehicle diagnostics and firmware data
  • Batch sensor readings from edge devices
  • Rich business events for analytics

Event Grid Standard: Autoscale Up and Down (Preview) - Coming Soon

Applies to both MQTT and non-MQTT workloads.

What it solves

Event-driven systems rarely operate at a constant rate. Traffic patterns fluctuate throughout the day, with predictable peaks, seasonal surges, and unexpected bursts that can quickly overwhelm static infrastructure.

Think about:

  • Morning factory startup
  • Fleet check‑ins at the top of the hour
  • Flash sales or system bursts

Manually sizing infrastructure leads to:

  • Over‑provisioning (higher cost)
  • Under‑provisioning (missed events)

What’s new

Azure Event Grid Standard Namespace now supports Autoscale Up and Down, automatically adjusting capacity based on real-time workload demand. Whether you're running MQTT-based IoT workloads or event-driven applications using HTTP, AMQP, or CloudEvents, Event Grid dynamically scales resources to match traffic patterns without manual intervention.

As demand grows, Event Grid automatically adds capacity to absorb increased traffic and maintain performance. When activity subsides, resources scale back down to optimize efficiency and reduce costs.

Why it matters

 With Autoscale, customers can focus on building applications instead of managing infrastructure and reap benefits like:

  • Scale seamlessly during traffic spikes without pre-provisioning for peak demand.
  • Reduce costs during quieter periods by automatically scaling capacity down.
  • Maintain consistent performance and reliability across changing workloads.
  • Eliminate manual tuning and capacity planning, reducing operational overhead.
  • Optimize resource utilization while supporting millions of devices and high-volume event streams.

Use case: A Modern Event-Driven Manufacturing Platform

A smart manufacturing company uses Microsoft to connect factory machines, sensors, edge gateways, and enterprise applications through a single scalable eventing platform. Devices publish rich telemetry and diagnostic payloads using MQTT, while cloud applications send operational and business events using HTTP. The company has steady traffic during the day, a large spike during shift changes, and much lower usage overnight. With autoscale, Event Grid adjusts capacity automatically, so performance stays strong when traffic is high and costs stay more efficient when traffic is low.

 

Autoscale intelligently to match changing workload demands

Common use cases

  • Shift‑based manufacturing systems
  • Connected vehicle platforms
  • Event‑driven commerce backends
  • Analytics pipelines with bursty data

Building IoT platforms, manufacturing and automotive solutions, or high-scale event-driven applications?

Azure Event Grid MQTT Broker now delivers larger messages, subscription Identifiers, and autoscale up/down, helping you simplify operations, improve performance, and optimize costs all on a single eventing platform.

Event Grid Basic: Powering Event Driven Payments with Stripe (GA)

Developers can seamlessly route Stripe events into Azure Event Grid to build scalable, event driven architectures without managing webhooks or custom brokers. Event Grid acts as a fully managed event broker between Stripe and Azure services.

Azure Event Grid now delivers Stripe events directly to Azure subscribers, including:

  • Azure Functions
  • Logic Apps
  • Event Hubs
  • Service Bus
  • And more

With Event Grid’s native integration with Microsoft Fabric, Stripe events can also be ingested as continuous streams, enabling real time transformation, enrichment, and analytics within Fabric. Learn more.

Read the whole story
alvinashcraft
15 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

15 productivity features in the new Outlook for Windows

1 Share

Hello, Outlook community. I’m Vicki Milton, a Principal Product Manager on the Outlook team.

Over the last year, we’ve added important capabilities across areas such as offline support, shared mailboxes, and PST files. Alongside those milestones, we've continued to deliver smaller improvements that help people work more efficiently throughout the day.

This article highlights 15 productivity features in the new Outlook for Windows that can help you stay organized, reduce routine effort, and keep important work moving.

Mail features

Email remains central to how many people manage communications, priorities, and follow-up. Outlook includes familiar tools for composing and organizing messages, along with newer capabilities that can help reduce friction and make inbox management more efficient.

  1. Pin a mail: Keep important messages easy to find. The Pin feature keeps a selected email at the top of your inbox so it remains visible as new messages arrive. This can be useful for items you need to reference often or do not want to lose track of, such as travel details, approvals, or active requests. By keeping priority messages in view, Pin can reduce time spent searching and help you stay focused on current work.

 

 

 

 

  1. Snooze a mail: Return messages when they are relevant again. Snooze lets you temporarily remove an email from your inbox and have it reappear at a time you choose. This can help keep your inbox focused on messages you can act on now while ensuring follow-up items come back when they are timely. It is particularly useful for requests that depend on additional information, scheduled tasks, or work you plan to handle during dedicated focus time.

 

 

 

 

  1. Add multiple categories at the same time: Organize messages with fewer steps. If you use categories to manage incoming mail, Outlook makes it possible to apply more than one category in a single action. This can help when you need to capture multiple types of context, such as project, priority, or follow-up status, without reopening menus repeatedly. It is especially useful when processing a large number of messages.

 

 

 

  1. Sweep: Reduce repetitive inbox cleanup. Sweep lets you create automatic actions for messages from a specific sender. For example, you can delete promotional mail after a set period, keep only the latest message in a thread, or move recurring updates to a folder. This can help reduce manual cleanup and keep your inbox more focused on items that need attention.

 



 

  1. Schedule Send: Write on your schedule and deliver at the right time. Schedule Send lets you prepare messages when it is convenient for you and send them later at a time that works better for the recipient. This can improve visibility, support more intentional communication, and reduce the need to rely on reminders or leave messages in Drafts.

 

 

  1. Simplified folder sharing: Share folders more simply. Sharing a mail folder has traditionally required extra permission steps, especially for nested folders. Now, when you share a folder, Outlook can automatically apply the visibility permissions needed for its parent folders. This can reduce setup effort, help avoid access issues for recipients, and make folder sharing easier to complete with confidence.

Calendar and meeting features

For many people, the workday is shaped by meetings, schedule changes, and the need to stay aligned on what comes next. Outlook includes calendar and meeting capabilities that can help simplify planning, reduce coordination overhead, and make follow-up easier.

  1. Follow a meeting: Stay informed without attending live. The Follow RSVP option lets you indicate that you will not attend a meeting but still want access to the recap. This can be helpful when schedules overlap or when a meeting is useful to monitor without joining in real time. It can help you stay connected to outcomes and shared materials while keeping your calendar more manageable.

 

 

  1. Save calendar views: Return to the calendar setup you need more quickly. Saved Views let you store specific calendar combinations and switch back to them without rebuilding the same view each time. This can save time for people who move frequently between personal, team, and project schedules. It also can make it easier to review the right set of calendars for different planning tasks.

 

 

  1. Improved meeting tracking: Work with meeting responses more efficiently. Outlook includes tools that make it easier for organizers to review and manage meeting responses. You can sort attendee lists, search for names in the Tracking view, and copy or download response details when needed. These capabilities can be especially useful for larger meetings where attendance information needs to be reviewed quickly.

 

 

  1. Meeting recap: Find follow-up materials in one place. After a Teams meeting, the calendar event in Outlook can surface a Meeting recap with links to the recording, transcript, and shared files. This can make it easier to review what was discussed, confirm details, or catch up afterward. By keeping these materials together, Meeting recap can reduce the time it takes to get oriented after a meeting.

 

 

 

  1. Filtered views: Reduce visual clutter in your calendar. Filters let you hide meetings you are not attending and limit the distraction of declined or informational events. This can make it easier to scan your schedule, identify conflicts, and focus on the meetings that need your attention. For people with full calendars, it can help make planning more straightforward.

 

 

  1. Change a recurring event: Update future meetings while preserving earlier ones. When plans change, Outlook lets you edit the current event and all following events in a recurring series. This can make it easier to adjust details such as time, location, or agenda going forward without changing the record of past meetings. It can simplify updates for organizers and reduce disruption for attendees.

 

 

Personalization and settings

Settings can play a practical role in day-to-day productivity. A few adjustments can make it easier to focus, move between accounts and calendars, and work in a way that fits your preferences. Here are several settings-related features that can help make Outlook feel more streamlined and manageable.

  1. Rename your email accounts: Make the right inbox easier to recognize. If you use multiple accounts in Outlook, you can assign each one a custom name. This can help you tell accounts apart more quickly, reduce the chance of sending from the wrong inbox, and make navigation simpler as you move between accounts during the day.

 

 

 

 

  1. Modern themes: Choose a look that supports comfort and clarity. Outlook includes theme and color options that let you tailor the experience to your preferences. Visual settings can influence readability and comfort, especially for people who spend much of the day in email and calendar. Options such as Dark Mode and color customization can help make the interface feel easier to use over time.

 

 

 

  1. Keyboard shortcuts: Keep familiar ways of working. In Outlook, you can choose the shortcut style you prefer in Settings. This can help you maintain existing habits, reduce adjustment time, and complete common tasks with fewer steps. For people moving from classic Outlook or Outlook on the web, shortcut flexibility can make the transition more consistent.

 

 

 

 

These features reflect a broader effort to help people work more efficiently in the new Outlook for Windows. Whether you are managing a high volume of email, coordinating a full calendar, or tailoring the experience to match your workflow, these updates are designed to reduce effort and improve day-to-day productivity.

For more information and step-by-step guidance, see the Microsoft Support articles and the Learning Path.

 

Read the whole story
alvinashcraft
15 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Data Modeling and Partitioning in Azure Cosmos DB

1 Share

For many database developers, the first experience with Azure Cosmos DB can feel both exciting and uncomfortable.

Exciting because Cosmos DB gives us a globally distributed, highly scalable, low-latency database platform.

Uncomfortable because it forces us to rethink habits we learned from years of relational database design.

If you come from SQL Server, Oracle, PostgreSQL, or another relational database engine, your instincts are probably well trained around normalization, foreign keys, joins, relational constraints, and designing tables around entities. Those instincts are valuable, but they are not always the right starting point when designing for Azure Cosmos DB.

One of the most important lessons in Cosmos DB is this:

You do not start by asking, “What are my tables?”
You start by asking, “How will my application read and write the data?”

That shift changes everything.

A great Microsoft session titled Data Modeling and Partitioning in Azure Cosmos DB by Leonard Lobel explains this beautifully. The session walks through the real-world challenge that many developers face when moving from a relational mindset to a document database mindset: how to structure data, how to choose containers, when to denormalize, when to combine multiple entity types, and how partitioning affects performance, scalability, and cost.

This topic is not optional knowledge for Cosmos DB developers. It is foundational.

If you get the data model and partitioning strategy wrong, Cosmos DB can become expensive, inefficient, and frustrating. If you get them right, Cosmos DB can deliver tremendous performance and scale.

Let’s break down the major lessons:

Cosmos DB Is Not Just a Place to Store JSON

A common mistake is to think of Azure Cosmos DB as simply “SQL Server, but with JSON documents.”

That is the wrong mental model.

Cosmos DB is a distributed database designed for scale. It stores JSON documents, but the real power comes from how those documents are grouped, partitioned, indexed, queried, replicated, and charged.

In a relational database, we often design around normalized tables:

  • Customers
  • Orders
  • Order Details
  • Products
  • Addresses
  • Categories

Each concept gets its own table. Relationships are represented through foreign keys. Queries reconstruct the business object using joins.

In Cosmos DB, that same approach can become painful.

Why?

Because distributed databases behave differently. Joins across large distributed datasets are not the same as joins inside a relational engine. Network boundaries, partitions, request units, and query fan-out matter. The data model must be designed with the distributed nature of the platform in mind.

That means Cosmos DB modeling is less about theoretical normalization and more about practical application behavior.

The Most Important Question: What Are Your Access Patterns?

In relational design, we often begin with the entity relationship diagram. In Cosmos DB, we begin with access patterns.

Before creating containers and partition keys, we need to ask questions like:

  • What does the application need to retrieve most often?
  • Which data is always read together?
  • Which data changes together?
  • Which queries must be extremely fast?
  • Which writes are frequent?
  • Which entities grow without limit?
  • Which operations must be transactional?
  • Which fields are used to filter data?
  • Which fields are used to route requests to a partition?

These questions drive the model.

For example, imagine an e-commerce system. In a relational database, an order may be stored across several tables: Order Header, Order Details, Customer, Address, Product, and Payment. But in Cosmos DB, if the application typically retrieves an entire order with its line items, shipping address, and order status, it may make more sense to store that order as a single document.

Instead of reconstructing the order through joins, you retrieve one document.

That is a huge mindset shift.

The goal is not to eliminate all relationships. The goal is to model data so the most important application operations are efficient, predictable, and scalable.

Embedding vs. Referencing: The Core Modeling Decision

One of the biggest Cosmos DB design decisions is whether to embed related data inside the same document or reference it as a separate document.

Embed data when it is naturally contained

Embedding works well when related data is owned by the parent and usually read together.

For example, an order and its order lines are a strong candidate for embedding:

{
  "id": "order-1001",
  "type": "order",
  "customerId": "customer-42",
  "orderDate": "2026-06-03",
  "status": "Shipped",
  "items": [
    {
      "productId": "product-10",
      "name": "Mountain Bike",
      "quantity": 1,
      "unitPrice": 1200
    },
    {
      "productId": "product-20",
      "name": "Helmet",
      "quantity": 1,
      "unitPrice": 75
    }
  ],
  "shippingAddress": {
    "street": "123 Main Street",
    "city": "Orlando",
    "state": "FL",
    "postalCode": "32801"
  }
}

This model is powerful because the application can retrieve the full order in one read operation.

No joins.

No multi-step lookup.

No extra round trips.

This is one of the major advantages of document modeling.

Reference data when it is large, shared, or independently updated

Embedding is not always the right answer.

If a related entity is large, reused by many documents, or updated independently, referencing may be better.

Product catalog data is a good example. A product may appear in thousands of orders. You probably do not want every product update to require updating thousands of historical order documents.

So you might store product details separately and only copy the product information needed at the time of the order.

For example, the order line may store:

{
  "productId": "product-10",
  "name": "Mountain Bike",
  "quantity": 1,
  "unitPrice": 1200
}

That preserves the historical truth of the order while avoiding the need to join to the current product record every time the order is displayed.

This is an important Cosmos DB principle:

Denormalization is not duplication for the sake of duplication. It is duplication for performance, scalability, and read efficiency.

Denormalization Is Not a Dirty Word

Relational developers are often taught to avoid duplication. In normalized relational design, duplication can create update anomalies and data integrity issues.

But in Cosmos DB, strategic duplication is often the correct design.

Why?

Because distributed databases reward locality.

If the data needed by a screen, API call, or business operation is stored together, the application can retrieve it efficiently. If that data is scattered across containers and partitions, the application may pay more in latency, request units, and complexity.

Denormalization is not about being careless. It is about being intentional.

A good Cosmos DB model may store the same data in multiple shapes for different access patterns. For example:

  • A customer document optimized for customer profile reads
  • An order document optimized for order history
  • A product document optimized for catalog browsing
  • A read-optimized projection optimized for a dashboard or search screen

This is very different from relational modeling, where we often try to maintain one canonical normalized structure and derive everything else through queries.

In Cosmos DB, it is common to design documents that directly serve the application.

Containers Are Not Tables

Another common mistake is to map every relational table to a Cosmos DB container.

Customers table becomes Customers container.

Orders table becomes Orders container.

Products table becomes Products container.

OrderDetails table becomes OrderDetails container.

That may look familiar, but it is often not optimal.

A Cosmos DB container is not simply the equivalent of a table. A container is a scalability and partitioning boundary. It has a partition key. It has throughput. It stores documents. It may contain multiple document types. It can scale horizontally across partitions.

That means we should not automatically create one container per entity type.

Sometimes it makes sense to store multiple entity types in the same container, especially when they share a partition key and are queried together.

For example, in a customer-centric system, you might store customer profile documents, order documents, support ticket documents, and address documents in the same container using a shared partition key such as customerId.

{
  "id": "customer-42",
  "type": "customer",
  "customerId": "customer-42",
  "name": "Contoso Bikes"
}
{
  "id": "order-1001",
  "type": "order",
  "customerId": "customer-42",
  "orderDate": "2026-06-03"
}
{
  "id": "ticket-9001",
  "type": "supportTicket",
  "customerId": "customer-42",
  "status": "Open"
}

With this design, related data for a customer can be colocated in the same logical partition.

That can make customer-centric queries efficient.

But this design only works if it matches the application’s access patterns.

The lesson is simple:

Do not design containers by copying relational tables. Design containers around workload, partitioning, and query patterns.

Partitioning Is the Heart of Cosmos DB Design

Partitioning is one of the most important Cosmos DB concepts.

Cosmos DB scales by distributing data across partitions. The partition key determines how data is logically grouped and how requests are routed.

When you create a container, you choose a partition key path, such as:

/customerId

or

/tenantId

or

/categoryId

Each document has a partition key value. Documents with the same partition key value belong to the same logical partition.

For example, if the partition key is /customerId, all documents with customerId = customer-42 are grouped into the same logical partition.

That matters because efficient Cosmos DB design depends heavily on routing operations to the right partition.

A good partition key helps Cosmos DB distribute data and workload evenly.

A bad partition key creates hot partitions, expensive queries, and scalability bottlenecks.

The Partition Key Is Not Just a Technical Setting

The partition key is a business design decision.

It affects:

  • How data is distributed
  • How queries are routed
  • How throughput is consumed
  • How scalable the workload becomes
  • How transactional operations are scoped
  • How expensive queries may be
  • Whether the application can grow cleanly over time

This is why choosing a partition key should never be treated as a minor setup step.

It is one of the most important architecture decisions in Cosmos DB.

A good partition key usually has three qualities:

1. High cardinality

The key should have many possible values.

For example, customerId, tenantId, deviceId, or userId may provide many distinct values.

A low-cardinality key like status is usually a poor choice because there may only be a few values such as Pending, Active, Closed, or Cancelled. That can concentrate too much data and traffic into a small number of partitions.

2. Even distribution

The key should distribute data and requests evenly.

High cardinality alone is not enough. If one customer, tenant, or device receives most of the traffic, that partition can still become hot.

For example, in a multi-tenant system, tenantId may look like a good partition key. But if one tenant is responsible for 80% of the workload, the design may create a hot partition.

3. Query alignment

The key should align with common query patterns.

If most queries filter by customer, then /customerId may be a strong candidate.

If most queries filter by tenant and user, then a hierarchical or synthetic partition strategy may be better.

The key point is that partitioning and querying cannot be designed separately. They must be designed together.

Request Units: The Currency of Cosmos DB

Cosmos DB uses Request Units, or RUs, to measure the cost of operations.

Reads cost RUs.

Writes cost RUs.

Queries cost RUs.

Stored procedures cost RUs.

Indexing impacts RUs.

The more work Cosmos DB has to do, the more RUs are consumed.

This is why data modeling matters so much. A poor model can turn a simple application operation into an expensive cross-partition query. A good model can make the same operation efficient and predictable.

For example:

  • Reading one document by id and partition key is usually very efficient.
  • Querying across many partitions is more expensive.
  • Returning large documents costs more than returning small documents.
  • Complex queries cost more than point reads.
  • Indexing every property may increase write costs.

This is why Cosmos DB design must consider both performance and cost.

In relational databases, we often focus heavily on query plans and indexes. In Cosmos DB, we must also focus on how many RUs each operation consumes and whether the model supports efficient partition routing.

Point Reads Are Gold

One of the best operations in Cosmos DB is the point read.

A point read retrieves a document by its id and partition key.

That is the most direct path to the data.

For example:

id = order-1001
partition key = customer-42

When the application knows both values, Cosmos DB can route the request directly to the correct logical partition and retrieve the document efficiently.

This is why many Cosmos DB designs aim to make the most common operations point reads or single-partition queries.

The more your application can avoid broad cross-partition scans, the better your performance and cost profile will usually be.

Cross-Partition Queries Are Not Evil, But They Must Be Understood

A cross-partition query is a query that may need to search across multiple partition key values.

Sometimes cross-partition queries are necessary. Cosmos DB supports them. But developers must understand their cost.

A query that touches many partitions may consume more RUs and have higher latency than a query targeted to one partition.

For example, this query may be efficient if customerId is the partition key:

SELECT * FROM c
WHERE c.customerId = "customer-42"

But this query may fan out across many partitions:

SELECT * FROM c
WHERE c.status = "Pending"

If the container is partitioned by customerId and status is not part of the partition strategy, Cosmos DB may need to search many partitions to find matching documents.

That does not mean the query is forbidden. It means you must understand the tradeoff.

For reporting, analytics, dashboards, and broad search scenarios, you may need a separate read model, materialized view, analytical store, or different container design.

Transaction Boundaries Matter

Cosmos DB supports transactional operations within a logical partition.

That makes partition-key design even more important.

If multiple documents need to be updated transactionally, they should usually share the same partition key value.

For example, if customer profile updates, customer preferences, and customer audit events must participate in operations scoped to one customer, partitioning by customerId may be useful.

But if related documents are scattered across different partition key values, you may lose the ability to perform simple transactional operations across them.

This is another reason why the partition key is not just a storage decision. It is a consistency and transaction design decision.

The Danger of Hot Partitions

A hot partition happens when too much traffic targets one partition key value or a small subset of partition key values.

For example, imagine a container partitioned by tenantId.

That sounds reasonable for a SaaS application. But if one tenant is much larger than the others, that tenant may dominate the workload.

The result can be throttling, uneven RU consumption, and poor scalability.

This is why partition-key selection must consider not just the number of values, but the distribution of reads and writes across those values.

Ask yourself:

  • Will one customer become huge?
  • Will one tenant dominate traffic?
  • Will recent dates receive most writes?
  • Will one category get most queries?
  • Will one status value contain most records?
  • Will one partition key value grow without limit?

A partition key that looks good during development may fail under production workload.

Synthetic and Hierarchical Partition Keys

Sometimes no single property is good enough as a partition key.

In that case, we may need a synthetic partition key.

A synthetic partition key combines multiple values into one partition key value.

For example:

tenantId|customerId

or

region|tenantId

or

customerId|orderYear

This can help distribute data more evenly while still supporting important query patterns.

Azure Cosmos DB also supports hierarchical partition keys, which allow multiple levels in the partitioning strategy. This can be especially useful in multi-tenant systems where the first level may be tenantId, but additional levels help distribute large tenants more effectively.

The goal is always the same:

Distribute data and workload evenly while preserving efficient query routing.

Common Mistakes Developers Make

Mistake 1: Creating one container per table

This often recreates a relational model without gaining the benefits of document modeling.

Mistake 2: Avoiding denormalization

Trying to keep everything normalized can create excessive queries, joins, and round trips.

Mistake 3: Choosing a low-cardinality partition key

Keys like status, type, region, or category may not distribute data well enough by themselves.

Mistake 4: Ignoring access patterns

A beautiful theoretical model can perform terribly if it does not match how the application actually uses data.

Mistake 5: Forgetting about RU cost

Every design decision affects cost. Query shape, document size, indexing, partitioning, and consistency all matter.

Mistake 6: Designing only for today’s data volume

A partition key may work with 10,000 records but fail with 100 million records.

Mistake 7: Assuming Cosmos DB works like a relational database

Cosmos DB is a distributed NoSQL database. It requires a distributed systems mindset.

The Big Lesson for Database Developers

The most important lesson from this topic is that Cosmos DB data modeling and partitioning are inseparable.

You cannot design the document model first and pick the partition key later as an afterthought.

You cannot choose the partition key without understanding queries.

You cannot estimate cost without understanding RUs.

You cannot optimize performance without understanding how data is distributed.

Everything is connected:

  • Data model
  • Partition key
  • Query patterns
  • RU consumption
  • Transaction scope
  • Scalability
  • Cost
  • Application behavior

This is why Cosmos DB design is both an art and an engineering discipline.

Lino’s 2 Cents:

Azure Cosmos DB is an incredible platform, but it rewards developers who design intentionally.

The best Cosmos DB solutions do not come from copying relational schemas into JSON documents. They come from understanding how the application works, how users access data, how data grows, and how Cosmos DB distributes workload across partitions.

For database developers, this is a critical shift.

Relational modeling teaches us to protect data integrity through normalization.

Cosmos DB modeling teaches us to protect performance and scalability through access-pattern-driven design, denormalization, and intelligent partitioning.

Both skills matter.

But when building with Cosmos DB, the winning design is the one that serves the workload efficiently.

So before creating your next Cosmos DB container, pause and ask:

What will my application actually do with this data?

That question is the beginning of good Cosmos DB design.

The Training Boss stands ready to engage with your organization to reach the best architecture for your CosmosDB database.  Reach out today

The post Data Modeling and Partitioning in Azure Cosmos DB appeared first on The Training Boss.

Read the whole story
alvinashcraft
16 minutes ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories