Ed‑Fi Data Management Service: Moving to a Relational Backend
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.
