Ember Data 3.x and Beyond: Going Off The Rails (Part 2)
This is Part 2. Read Part 1: Drafting on Rails for the early history of Ember Data, the JSON:API migration, and the emergence of community extensions like model-fragments.
The LinkedIn Era: Ember Data 3.x and the GraphQL Ghost
Part 1 ended with a promise: the Ember Data team acknowledged that community addons like ember-data-model-fragments, ember-m3, and ember-data-storefront were addressing genuine needs, and that new public APIs would provide a stable foundation for them. What actually happened was the opposite.
Ember Data 3.x represented a behind-the-scenes architectural shift, one that most users only experienced through its downstream effects. LinkedIn sponsored significant private development work aimed at making Ember Data compatible with GraphQL.
The internal APIs were reworked extensively. Hooks that addons relied upon changed. The very addons the team had praised for "addressing the genuine needs of our consumers" broke. Not in major releases where breaking changes are expected, but in minor versions that created ongoing maintenance burdens.
Here's the twist: due to employer conflicts and corporate priorities, the actual GraphQL compatibility code was never publicly released. The community absorbed the cost of the architectural changes (broken addons, migration work, learning new internal patterns) without receiving the feature that justified those changes.
This is the risk of corporate-sponsored open source development: when the sponsoring company's priorities shift, the community is left holding the bag.
The Churn Accelerates: Breaking Changes in Minor Releases
Ember's versioning philosophy has historically emphasized stability. The framework itself follows semantic versioning with rare exceptions. Ember Data, however, developed a pattern of introducing breaking changes in minor releases.
The 3.x cycle was brutal for extensions. Many addons that had worked for years broke repeatedly as internal APIs shifted. Some maintainers rebuilt and continued; others walked away. ember-data-model-fragments was among those that persevered, its maintainers doing the thankless work of keeping up with a moving target.
Then came 4.6. In the middle of the 4.x series, not a major release, not even the start of a new cycle, model-fragments hit a fatal breaking change. The internal APIs it depended on were reworked in ways that couldn't be papered over. For applications that had invested years in model-fragments, this wasn't a deprecation warning or a migration path. It was a wall.
The response from the Ember Data team remained consistent: those packages were using private APIs, so they had no right to expect stability. But the public API still couldn't accomplish what those packages needed to do. The community was caught in a loop: public APIs were insufficient, private APIs were the only option, and using them was treated as a moral failing when they broke.
The Big Bang Rewrite: Ember Data 5.x
As TypeScript adoption became ubiquitous across the JavaScript ecosystem, Ember Data offered no official type definitions. For years, the only option was community-maintained types on DefinitelyTyped. The messaging was contradictory: there were no official types, but you also shouldn't use the community types. Developers who needed TypeScript (which, by the mid-2020s, meant most professional teams) were left to choose between no types, unsupported types, or maintaining their own.
Official TypeScript support finally arrived in Ember Data 5, along with everything else. ED5 wasn't an incremental improvement; it was a ground-up rewrite. New primitives, new architecture, new mental model. The intention was to provide a more flexible, lower-level foundation that could support diverse use cases.
In practice, this meant yet another migration. Applications that had survived the JSON:API pivot, the LinkedIn-era breakages, and the minor-version churn now faced learning a fundamentally different approach to the same problems they'd been solving for years. The teams who most needed TypeScript support were stuck on 3.28, unable to migrate without a full rewrite. The official types arrived years late, in a version that most of the community couldn't practically use.
The project has been renamed to "WarpDrive" and the repository moved to a new organization. The rebrand itself is telling: "WarpDrive" is nearly impossible to search for, competing with Star Trek references, actual physics concepts, and countless other projects. Looking at the actual monorepo, the scope creep is remarkable for what was once a data persistence library:
- @warp-drive/diagnostic: A custom test runner competing with QUnit, Vitest, Jest, and Mocha
- @warp-drive/holodeck: A custom HTTP mocking library, despite the community having long settled on Mirage.js
- @warp-drive/tc39-proposal-signals: An implementation of the TC39 Signals proposal, bleeding-edge spec work
- @warp-drive/react, @warp-drive/svelte, @warp-drive/vue: Framework bindings for React, Svelte, and Vue
- eslint-plugin-warp-drive: A custom ESLint plugin
- @warp-drive/build-config: Build configuration tooling
The project uses Bun for type checking (bun run check:test-types), an unusual choice in an Ember ecosystem that has standardized on npm and pnpm.
Why is a data persistence library building its own test runner, mocking framework, and TC39 polyfills? Why is an Ember addon shipping React, Vue, and Svelte packages? Instead of solving the problems that drove users away (upgrade paths, ecosystem compatibility, stable APIs), the team is reinventing adjacent tooling that the community already solved years ago, while expanding to frameworks where adoption is virtually nonexistent.
Ember Data 5 has found another corporate sponsor, continuing the pattern of external funding driving development priorities. But corporate sponsorship doesn't solve the fundamental problem: there is no clear upgrade path. Each major version has left applications stranded, with migration guides that assume you weren't using any of the community extensions that made Ember Data practical for real-world use.
The Broken Promises
Remember that April 2023 blog post that acknowledged community addons were "addressing the genuine needs of our consumers"? The same post promised a path forward. New public APIs would let addon maintainers "rewrite to utilize public APIs and achieve improved stability." The team would bring "most of the ideas explored by each of these libraries into the core recommended experience."
That post announced plans for "lifting all tides," describing how the new request and cache APIs in 4.12 would enable "powerful replacements" and provide migration paths for applications stuck on older versions. For ember-data-model-fragments specifically, the post stated: "we commit to providing extensive time to assist in adding support for 4.12 to the current 3.28+ branch." It promised "a carrot and mechanism to leap quickly to 5.x."
It went further than blog posts. In a GitHub issue on the model-fragments repository, a detailed migration roadmap was posted directly to the affected community. It described "The Promised Land: 4.12+" with specific steps: first improve 4.6 support, then choose between two technical paths (a custom cache or a custom model), culminating in users being able to "incrementally re-write their apps to use SchemaModel instead of Model+ModelFragments." The post even promised: "I'll be working with @RSG and anyone else interested to achieve this."
By September 2023, another blog post announced the 4.12 LTS with even more commitments: support "beyond simple bug-fixes," backporting of CacheHandler improvements and runloop removal, and three codemods "in development" for migration assistance. The post explicitly called out to users "stuck on 3.x or 4.x versions" asking for feedback about blockers. The message was clear: help is coming.
None of this happened. The model-fragments migration assistance never materialized. SchemaRecord exists as a package (@warp-drive/schema-record), but the promised stable 4.12-compatible version with a clear migration path never arrived. The npm lts tag still points to version 0.0.3, and the lts-4-12 tag shown in the README doesn't exist on npm at all. The detailed GitHub roadmap sits abandoned. Those three codemods "in development"? The PRs were opened in September 2023 and remain unmerged to this day: #8884, #8887, #8893, sitting open for years while the project pivoted to React bindings and custom test runners.
Teams who read these posts and made technical decisions based on those commitments were left holding the bag. This pattern of announcing intentions as if they were roadmaps, and then abandoning them, has made it impossible to plan around Ember Data's future.
The Numbers Don't Lie
And even now, the 5.x series attempts to address all technical debt simultaneously: removing the Ember.Object dependency, adding TypeScript, migrating to Vite builds, introducing new primitives. Each of these is defensible in isolation, but taken together they mean the high-level API that made Ember Data valuable is gone. What remains is a collection of building blocks where a useful tool used to be. You're no longer adopting a data layer; you're assembling one from parts, with documentation that assumes you already understand the architecture you're trying to learn.
The community response is telling. Here are the weekly npm download stats as of January 2026:
| Version | Weekly Downloads | Notes |
|---|---|---|
| 4.6.6 | 11,845 | Last version before model-fragments broke |
| 4.12.8 | 10,012 | LTS 4.12 |
| 3.28.13 | 4,453 | LTS 3.28 |
| 5.3.13 | 2,934 | Current LTS |
| 5.8.1 | 1,053 | Latest stable |
The most downloaded versions are 4.6.6 and 4.12.8, not the latest 5.x releases. Notably, 4.6.6 is the version just before the fatal model-fragments breaking change, suggesting many teams stopped upgrading at exactly that wall. The current LTS (5.3.13) gets fewer downloads than a 3.x release from years ago. Combined, 3.x and 4.x downloads (64,000+) still significantly outpace 5.x adoption (~20,000). This isn't because older versions are perfect; it's because teams have exhausted their appetite for migration, and because the path forward is not a path at all. It's a rewrite.
Where This Leaves Us
The original value proposition of Ember Data was tight integration with Rails conventions, developer happiness, sensible defaults, and a framework that got out of your way. Over the years, that value was systematically abandoned in pursuit of abstraction. Each pivot promised flexibility but delivered complexity. The WarpDrive rebrand, the React/Vue/Svelte packages, the custom test runners: none of this serves the Rails developers who made Ember Data successful in the first place.
I want to be clear: open source is often thankless, volunteer work. People pour their limited time into projects because they believe in them. I'm not writing this to condemn individuals who have faced genuinely difficult technical problems. But the structure matters. The ever-shifting vision made it nearly impossible for the community to contribute meaningfully. Much of the critical development happened behind closed doors, in corporate contexts the community couldn't participate in. When architectural decisions are made in private and the community only sees the downstream breakage, there's no opportunity for course correction.
If you're building a new application and considering Ember Data, I find it very hard to recommend. The pattern is too clear: corporate sponsors come and go, architectural visions shift, and there is never a stable upgrade path. You're not adopting a library; you're signing up for a series of rewrites with no end in sight.
If you're maintaining an existing Ember Data application, you have my sympathy. The choice between another migration and staying on an aging version is not a good one.
And if you're leading an open source project: your users are not abstract. They're people with limited time, trying to ship software. Every architectural pivot has a human cost. Upgrade paths are not optional. If there's no clear migration between major versions, you're not maintaining a library, you're publishing a series of unrelated projects that happen to share a name.
The code we write is only as good as the trust it earns, and trust, once broken repeatedly, is very hard to rebuild.