15 posts tagged with "ed-fi-api"

The Ed-Fi Alliance is pleased to announce the release of Ed-Fi API Publisher v1.4. This release adds support for Ed-Fi API v8, reads large sources faster with cursor paging, lets a failed run resume where it stopped, and reports through its exit code whether a run lost documents. It also moves the API Publisher to .NET 10.

Ed-Fi API v8 has been through a great deal of internal testing: unit and integration tests, end-to-end suites, and the performance comparison against the ODS/API. All of that tells us the platform behaves the way we expect. It does not tell us whether it behaves the way your integration expects. The only way to learn that is to point real client integrations — built by the organizations that will depend on the platform in production — at a running Ed-Fi API v8 instance and see what happens.

That is the purpose of the new Ed-Fi API v8 Pilot Test Kit: a self-contained Docker Compose environment, plus a structured pilot program, for exercising Ed-Fi API v8 with production-grade client integrations before broader market adoption.

(† indicates "coming soon")

Overview​

Since the move to a relational backend, the most common question from the community has been simple: how does it perform against the ODS API? We ran a shared test suite against both APIs, on both PostgreSQL and SQL Server, using the same dataset and request mix.

The short version: on PostgreSQL, Ed‑Fi API 8.1 comes out ahead on every workload we tested. On SQL Server, DeepPaging and FilteredRead are close to a tie, and Volume (writes) is behind. The reason is narrow and well understood: the change-version stamp triggers, the database triggers Ed‑Fi API 8.1 uses to keep each record's _etag, last-modified timestamp, and change-tracking version current on every write. We can point to exactly how much they cost and the work already underway to reduce it.

What This Means for Implementers​

• PostgreSQL: Ed‑Fi API 8.1 wins on writes, paging, and filtered reads against ODS API v7.3.2, on the same hardware and dataset.
• Where the win comes from: mostly a database CPU advantage on reads. The write path is faster too, but that doesn't mean it's cheaper to run across the board (more on that below).
• SQL Server: near ties on paging and filtered reads; behind on writes, traced to the change-version stamp triggers, a mechanism we've measured precisely and already scoped a fix for (see below).
• Read this as a snapshot, not a guarantee for your deployment. See the caveats in the "How We Tested" section below.

The Ed-Fi Alliance is excited to announce the release of Ed-Fi API v8.0 and MetaEd v4.8. Ed-Fi API v8.0 represents the next-generation evolution of the Ed-Fi ODS/API platform, delivering a modernized architecture while maintaining compatibility with existing Ed-Fi API integrations. Version 8 is designed as the long-term replacement for the legacy ODS/API platform.

Have questions about the transition from ODS/API to Ed-Fi API v8? See the Ed-Fi ODS/API and Ed-Fi API v8 FAQ for answers on the roadmap, timelines, and what to expect.

The Ed-Fi Alliance is excited to announce the release of Data Standard v6.1, ODS/API v7.3.2, Ed-Fi OneRoster Service, and MetaEd v4.7. These updates reflect continued collaboration with the Ed-Fi community and focus on advancing interoperability, modernizing the platform, and improving support for priority use cases.

Overview​

The Ed‑Fi Data Management Service (DMS) is evolving toward a relational backend, shaped by community feedback and real‑world implementation experience. Building on the proven Ed‑Fi ODS/API foundation, DMS modernizes the storage layer to address long‑standing operational challenges—such as wide composite keys and complex joins—through targeted structural changes.

By prioritizing a relational backend, DMS preserves the core strengths of the ODS: predictable schemas, strong referential integrity, and compatibility with relational tooling. The result is a service that feels familiar to teams with ODS experience and lowers the cognitive and migration cost of adoption.

What This Means for Implementers​

If you work directly with the ODS database today, DMS's data store will feel familiar, but with important structural differences:

• You still work with the same Ed‑Fi entities and natural keys
• Joins are simpler and narrower due to surrogate keys
• Person identity is clearer and no longer mediated by ODS-only integers
• Optional document caching can accelerate API reads

The sections below explain why these changes exist and how they affect database design and operations.

This post is written for database administrators, backend developers, data engineers, and solution architects who work with the Ed‑Fi ODS/API at the database level and are evaluating or planning a transition to DMS. Familiarity with the ODS schema and relational database concepts is assumed.

We’re excited to announce the 0.7 release milestone for the Ed-Fi Data Management Service (DMS).This release focuses on multi-tenancy foundations, operational cost optimizations, and improved performance for scalable deployments.

The Ed-Fi Alliance continues to advance its mission of enabling interoperability and scalable data solutions for education agencies. At the recent Ed-Fi Alliance Summit 2025, we shared updates from the Ed-Fi Technology Roadmap, highlighted recent releases, and previewed what’s coming in the next few years.

We’re thrilled to announce the Release Candidate 1 / v0.6.0 release milestone for the Ed-Fi Data Management Service (DMS). This release introduces Swagger UI, template databases, and completes critical end-to-end and compatibility testing. It also lays the groundwork for smoother integration and a better developer experience.

We’re excited to announce the 0.5 release milestone for the Ed-Fi Data Management Service (DMS), marking another step forward on our path toward the upcoming Release Candidate 1. This release delivers key features to support authorization, extensibility, and interoperability.