Ed‑Fi API 8 Performance: How It Compares to the ODS API
This post reflects the upcoming Ed‑Fi API 8.1 compared against the ODS API v7.3.2.
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.


