GraphQL Federation Schema Changes: From Months to Days with Hub

We've been building Hub with customers from the very beginning.

This is the story of one of those customers. A large enterprise running GraphQL Federation across dozens of subgraphs and multiple engineering teams.

We're sharing this with their permission, though we're keeping the specifics anonymous. The patterns, problems, and results are real.

They adopted GraphQL Federation two years ago. It was working, in the sense that queries resolved and the supergraph composed without errors.

But "working" and "working well" are different things.

Their federated graph had grown to over 60 subgraphs maintained by roughly 25 teams. The platform engineering team, which consisted of four people, was responsible for the schema registry, composition pipeline, and "helping teams work together."

That last part had consumed the job.

When we first talked to their lead architect, he put it simply:

We can compose the graph. We just can't evolve it.

He described a recent feature that required adding a handful of fields across three subgraphs. The implementation work was straightforward, and would require maybe two days per subgraph. The total elapsed time from request to production: nine weeks.

The breakdown:

• Week 1: The frontend team identified what they needed, couldn't figure out which teams owned the relevant entities, asked the platform team, who identified three affected subgraphs across two departments and set up a meeting.
• Week 2-3: The meeting happened. Disagreement on field naming. A follow-up meeting was scheduled.
• Week 4: Agreement on the schema design. Each team added the work to their sprint backlog.
• Week 5-7: Two of three teams implemented their changes. The third team was mid-sprint on something else and couldn't prioritize it.
• Week 8: All implementations done. Composition failed because of a misaligned entity key.
• Week 9: Fix applied. Feature shipped.

Nine weeks for what amounted to approximately six days of implementation work.

Before working with us, they'd tried several approaches:

A Confluence wiki documenting subgraph ownership and entity relationships. It was outdated within a month. Nobody maintained it because the schema changed faster than anyone could update docs.

Miro boards for schema design sessions. These worked for individual discussions but couldn't stay in sync with the actual graph. After a design session, someone had to manually translate the Miro board back into SDL and verify it against the current schema.

A Slack channel for schema change proposals. Proposals got lost in the noise. Critical reviews from affected teams were missed. There was no way to track whether all stakeholders had approved a change.

Monthly schema review meetings with all team leads. These became forums for airing grievances rather than productive design sessions. Attendance dropped after a few months.

None of these addressed the core issue: there was no single source of truth for what the graph looked like, who owned what, and how changes should be coordinated. The collaboration and governance gap that shows up once composition is solved but humans still have to coordinate.

We onboarded their platform team to WunderGraph Hub and imported their existing federated graph.

The first reaction from their lead architect:

I've been working with this graph for two years and this is the first time I can actually see it.

The visual canvas showed all types, fields, and relationships. Entity ownership was explicit. Cross-subgraph dependencies were visible at a glance.

Within the first week, they discovered:

• Three pairs of types that were semantically identical but named differently
• Two entities with no clear owner (teams had been reorganized, ownership hadn't been updated)
• A set of fields that had been deprecated in the schema but were still being served because nobody knew if any consumer still used them

Hub wasn't doing anything sophisticated, it was just making the existing graph visible in a way that a 10,000-line SDL file never could.

The real change came when teams started using Hub for schema change proposals.

A frontend engineer needed to add a loyaltyTier field to the Customer entity. Instead of asking the platform team who to talk to, they opened Hub, found the Customer entity, saw that it was owned by the Customer Data team, and created a proposal directly.

Hub automatically identified that the change also affected the Loyalty subgraph (which would need to provide the data) and routed the proposal to both teams for review.

The Customer Data team approved within a day. The Loyalty team had questions about the field's return type, left a comment on the proposal, and the discussion resolved in two days.

Total time from proposal to approved design: three days. No platform team involvement. No meetings scheduled. No Slack threads lost in noise.

The platform team defined naming conventions and schema design rules in Hub. Proposals are automatically checked against these rules before they're sent for review.

When a team proposed a field called custLoyaltyLvl, the governance check flagged it: naming convention requires full words, no abbreviations. The team updated it to customerLoyaltyLevel before anyone had to review it.

The platform team went from reviewing every field name manually to maintaining a set of rules that enforce themselves. They now spend their review time on architectural decisions — entity boundaries, relationship modeling, cross-domain patterns — work that actually requires their expertise.

After three months of using Hub, the team reported:

• Schema change cycle time: from an average of 6-8 weeks down to 1-2 weeks
• Platform team time on routing/coordination: from ~60% down to ~15%
• Schema design inconsistencies caught pre-merge: roughly 3x more than before (because automated checks catch what manual review misses)
• Cross-team schema proposals per month: up 4x (teams that previously avoided proposing changes because the process was too slow now participate actively)

The last metric is the most telling. The backlog of "features we'd build if schema changes weren't so painful" started shrinking for the first time.

When we checked in after the initial rollout, their lead architect said:

Hub didn't just make us faster. It changed how teams think about the graph. Before, the supergraph was the platform team's problem. Now it's everyone's product.

The platform team still sets the standards. They still make architectural decisions. But they're no longer the bottleneck for every field name and entity extension.

The senior architects on the team told us this was a paradigm shift for them, because they finally had clarity on what capabilities existed, what was missing, and how to distribute ownership effectively.

Working with this customer (and others in similar situations) taught us a few things:

1. Visibility alone is transformative. Before you can improve collaboration, people need to see the graph. A visual canvas that shows types, relationships, and ownership solves half the problem before you even get to proposals and governance. Engineers aren't the only ones who benefit. Designers, product owners, and other non-technical stakeholders take real value from exploring the graph visually. People who would shy away from thousands of lines of schema definition that looks like "code" can navigate the canvas immediately. It turns the supergraph from an engineering artifact into a shared product.

2. The platform team wants to stop being a switchboard. Every platform engineer we've talked to is frustrated by the same thing: they were hired to build infrastructure, and they spend most of their time answering questions — the platform bottleneck pattern we hear about constantly. Giving teams self-service access to the graph frees the platform team to do their real job.

3. Governance should be automated, not gate-kept. Manual reviews don't scale. Automated checks do. The platform team's role should be defining the rules, not enforcing them one-by-one.

4. Lowering the barrier creates demand. When schema changes are easy, teams propose more of them. This is a good thing. It mean that the API surface evolves to match what consumers actually need, instead of being frozen by process overhead.

If this story resonates with you, get in touch . We'd love to show you what Hub can do for your team.

Frequently Asked Questions (FAQ)