News

Microsoft Pushes OData Forward with New Previews

• By David Ramel
• 12/01/2025

Microsoft is continuing to modernize its Open Data Protocol (OData) stack, with new preview releases for both ASP.NET Core OData and the OData Model Builder, plus fresh research that proposes an evolutionary path called ODataX.

The company recently introduced coordinated preview updates that move core OData server tooling to .NET 10 and align dependencies with the upcoming OData Library (ODL) 9.x line.

OData is not as buzzy in the broader API conversation as it was in its early years, when it was a prominent effort to standardize rich, queryable REST APIs. Since then, alternatives such as GraphQL and other API styles have attracted mindshare, while OData has settled into a role as dependable infrastructure, especially in enterprise environments. That enterprise footprint remains substantial, particularly across Microsoft- and SAP-centric ecosystems, even as greenfield projects often choose other approaches.

Against that backdrop, Microsoft's latest tooling previews focus on keeping OData current with modern .NET, while an October 2025 ODataX paper argues for reducing adoption barriers without discarding the protocol's core strengths.

ASP.NET Core OData 10 Preview 1: .NET 10 And Native Date/Time Types
The ASP.NET Core OData team released ASP.NET Core OData 10.0.0 Preview 1 as a major modernization update that targets .NET 10.0 and updates key dependencies to preview builds in the OData .NET ecosystem.

Key changes include:

• .NET 10.0 support. The framework target advances to net10.0 to match the next .NET runtime.
• Dependency alignment. The preview updates OData Library (ODL) from 8.4.0 to 9.0.0-preview.3 and OData Model Builder from 2.0.0 to 3.0.0-preview.1, positioning the stack for a coordinated upgrade path.
• Native System.DateOnly and System.TimeOnly support. The release removes Microsoft.OData.Edm.Date and Microsoft.OData.Edm.TimeOfDay CLR wrapper types and replaces them with .NET's built-in structs.

Microsoft emphasizes that this change is breaking for apps that explicitly used the older EDM wrapper types in models. To migrate, developers need to retarget to .NET 10 and update model properties from Date to DateOnly and from TimeOfDay to TimeOnly, plus bump packages to the preview versions.

On the wire, the preview keeps protocol compatibility by continuing to surface Edm.Date and Edm.TimeOfDay in metadata, while handling serialization/deserialization so DateOnly and TimeOnly map to the OData formats (yyyy-MM-dd for dates and HH:mm:ss.fffffff for times). The team notes future work to address full replacement in the metadata layer.

OData Model Builder 3 Preview 1: Matching The Stack
Released a day earlier, OData Model Builder 3.0.0 Preview 1 mirrors the same modernization themes and is intended to line up cleanly with the ASP.NET Core OData 10 preview.

Highlights include:

• .NET 10 target framework. The Model Builder moves from net8.0 to net10.0.
• ODL 9.x compatibility. Dependencies such as Microsoft.OData.Edm and Microsoft.Spatial shift from 8.0.1 to 9.0.0-preview.3.
• Date/time modernization. Like ASP.NET Core OData 10, the Model Builder removes support for Microsoft.OData.Edm.Date and Microsoft.OData.Edm.TimeOfDay and adds full support for System.DateOnly and System.TimeOnly.
• New helpers for TimeOnly. The preview adds an AsTimeOnly() extension for primitive property configuration and an IsTimeOnly() helper for type detection, to keep parity with existing conventions.

For developers upgrading from Model Builder 2.x, the practical impact is largely centered on type replacement in entity models and configurations. Aside from that date/time switch, the company says the API surface remains the same.

ODataX Paper: A Progressive Evolution Of The Protocol
The related October 2025 research paper, "ODataX: A Progressive Evolution of the Open Data Protocol," examines why OData adoption remains concentrated in enterprise settings and proposes a backward-compatible evolution aimed at making OData easier to approach for modern web developers.

The paper identifies several adoption barriers:

• Syntax friction. The authors point to OData's operator vocabulary (for example, gt and eq) and dollar-sign system options as a learning curve compared to common URL query patterns.
• Ecosystem gaps outside Microsoft/SAP. The paper argues that client libraries and first-class tooling are less common in popular frontend stacks compared to GraphQL-focused tooling.
• Performance and safety concerns. Because OData allows expressive queries, deep expansions and complex filters can be expensive without safeguards, which can make services hesitant to expose OData broadly.
• Perception as enterprise-legacy adjacent. The authors say OData's association with long-lived enterprise platforms affects its appeal in newer app development.

ODataX addresses those issues through three main design principles: progressive complexity disclosure, performance by default, and backward compatibility with OData v4.

Concretely, the paper proposes:

• Simplified query syntax that maps to standard OData under the hood. Examples include filter=price>100,category:Books and sort=-price in place of $filter and $orderby with OData operators.
• Named query aliases, where a server can advertise or register common queries (such as “affordableBooks”) that expand to full OData expressions.
• Built-in query cost estimation, with configurable thresholds and error feedback when a query is too expensive, intended to prevent overload scenarios by default.
• Query-aware caching and normalization to improve cache hit rates across semantically equivalent queries.

The authors present ODataX as an evolution rather than a replacement, aiming to keep OData's standardized query strengths while smoothing first contact and operational safety.

What It Means for OData Developers
In the near term, Microsoft's preview tooling releases are about alignment and modernization: moving OData server packages to .NET 10, converging on ODL 9.x previews, and eliminating legacy EDM wrapper types in favor of native .NET date/time structs.

At the protocol level, the ODataX work suggests where the team could head next if broader adoption is a goal: keeping OData v4 compatibility while lowering day-one syntax friction and making performance guardrails part of the default experience.