WunderGraph

GraphQL Federation infrastructure, honestly reviewed. Built for backend engineers, not no-code users.

TL;DR

• What it is: WunderGraph Cosmo — an open-source (Apache-2.0) GraphQL Federation platform covering schema registry, router, observability, and a new governance layer called Hub. The direct alternative to Apollo Studio and GraphOS [README].
• Who it’s for: Backend engineering teams running federated GraphQL at scale. If you don’t know what GraphQL Federation is, this tool is not for you — and that’s not a knock, just honesty.
• Cost savings: One customer (SoundCloud) cut infrastructure costs 30%, from $14K/month to $9.75K/month after switching from their previous provider. Another (Acoustic) estimated $178K saved on engineering work alone [1].
• Key strength: Full Apache-2.0 license with no feature gating by license tier — everything open source, managed cloud optional. Router performance benchmarks show 8x better P99 latency and 8x more requests per second vs Apollo Router [website].
• Key weakness: 1,180 GitHub stars is modest for infrastructure tooling, which signals a smaller community than Apollo. All third-party sources for this review are WunderGraph’s own blog — truly independent benchmarks and reviews are scarce. Self-hosting requires Kubernetes expertise.

---

What is WunderGraph

WunderGraph Cosmo is a lifecycle management platform for federated GraphQL APIs. If your backend is a collection of services (Orders, Users, Inventory, Payments) and you want to expose them as one unified GraphQL endpoint to your frontend, that’s GraphQL Federation. Cosmo manages the infrastructure layer: the router that handles query planning, the schema registry that checks for breaking changes, the analytics that show you what’s failing and why [README][2].

The product is split into two pieces:

Cosmo is the open-source core: the Router (high-performance query planner written in Go), the Schema Registry with composition checks, the CLI for schema management, and a studio UI for exploring your federated graph. It also handles observability — metrics, tracing, distributed request tracking [README][2][4].

Hub is newer — a collaborative governance layer announced as “GraphQL Federation Reimagined” on the homepage. It adds a visual canvas for designing schemas before implementation, structured schema proposal workflows, and stakeholder review flows. The pitch: schema changes shouldn’t happen in Slack. Hub formalizes them [website].

The GitHub README is blunt about the positioning: “The open-source solution to building, maintaining, and collaborating on GraphQL Federation at Scale. The alternative to Apollo Studio and GraphOS.” Apollo’s GraphOS is the incumbent in this space, and it charges enterprise-tier SaaS prices for what Cosmo ships as Apache-2.0 open source.

One important note: WunderGraph has a history. The original WunderGraph product was a different API integration SDK (BFF framework). Cosmo is the company’s current focus — a pivot to GraphQL Federation infrastructure. The blog posts reference the earlier product, but this review covers Cosmo specifically.

---

Why engineering teams choose it

The evidence base here has a significant caveat: the five “third-party articles” provided for this review are all WunderGraph’s own blog posts. There are no independent review sites, no G2/Capterra pages, no r/graphql threads in the source list. What’s available are detailed case studies and technical blog posts from WunderGraph themselves. Take the numbers with appropriate skepticism, even though the case study companies (On The Beach, SoundCloud, Soundtrack Your Brand) are real, named organizations.

The Apollo migration case. On The Beach — a UK travel company handling 4 billion monthly clicks — built a custom GraphQL Federation internally, found it unmaintainable, then moved to Cosmo. The specific pains were: schema changes required deep domain knowledge across teams, composition errors were caught too late, and the homegrown router didn’t give them the request tracing they needed for debugging real-time travel pricing feeds. After migration: reduced infrastructure costs, improved developer experience with schema checks, and better performance for subscription-heavy features [1].

The compliance/on-prem angle. Apollo requires cloud connectivity for GraphOS features. Cosmo is explicitly designed so that nothing routes through WunderGraph’s infrastructure unless you choose managed cloud. For enterprises in financial services, healthcare, or EU-regulated industries, that distinction matters: audit logs, schema state, and routing all stay inside your network [4]. One WunderGraph blog post puts it directly: “In contrast to our main competitor, we made absolutely sure that you wouldn’t need some Cloud service to run Cosmo, but to make it optional.” [4]

The performance claims. The homepage shows benchmarks: Cosmo Router at 186ms P99 latency vs Apollo Router at 1.51 seconds vs Apollo Gateway at 9.01 seconds. Throughput: 1,167 requests/second for Cosmo vs 143 for Apollo Router vs 91 for Apollo Gateway. These are WunderGraph’s own benchmarks — independent verification would strengthen the claim, but the architectural reason is real: Cosmo’s router query planner is written in Go with a native execution engine, AST-JSON based result merging, and a cache warmer that precomputes query plans for high-traffic bursts. The Super Bowl case is referenced on the homepage, implying the cache warmer was validated under real-world spike load [website][README].

The license argument. Apollo’s GraphOS is proprietary SaaS. n8n-style “Fair-code” restrictions don’t apply here — WunderGraph Cosmo is a clean Apache-2.0 repository with a single license and no enterprise feature gating at the code level [3]. WunderGraph’s own post on this topic is surprisingly candid about why: “Enterprise Sales is not about selling features; it’s about selling a solution to a problem… What they buy is not about features, it’s about the relationship they have with us.” [3] Whether you find that reassuring or concerning as a self-hoster is a judgment call.

---

Features

Core routing and federation:

• Router with native high-performance query execution planner (Go) [README]
• Support for both monolithic and federated GraphQL architectures [README]
• GraphQL subscriptions via event streams: Kafka, NATS, Redis — router handles event translation, backends stay stateless [website]
• Cosmo Connect: map GraphQL schema fields to gRPC backend services, so existing gRPC backends don’t need rewriting [website]
• Multi-protocol support: GraphQL, REST, gRPC, Kafka composed into one supergraph [website]
• Single-flight query execution to avoid duplicate fetches [website]
• Cache warmer for precomputing query plans ahead of traffic spikes [website]

Schema management:

• Schema registry with full version history and composition checks [2]
• CLI-driven schema publishing, validation, and diff detection [2]
• Breaking change detection before merge — flags field/type/directive conflicts across subgraphs [2]
• Hub canvas for visual schema design and proposal workflows (newer feature) [website]
• Structured proposal → feedback → approval flow before implementation begins [website]

Observability:

• Built-in metrics and distributed tracing [README][4]
• Analytics on query performance and error rates [2]
• Studio UI for exploring the federated schema and running checks [2]

Developer tooling:

• MCP Gateway: connects Cosmo to Cursor, Windsurf, and VSCode — explore schemas and propose changes from inside your IDE without CLI context-switching [website]
• REST API [merged profile]
• Docker, Docker Compose, Helm, Kubernetes deployment targets [merged profile]

What’s not here: This is not a no-code tool, not a webhook automation platform, not an API gateway for REST-only stacks. If you’re not running GraphQL Federation with multiple subgraph teams, Cosmo is infrastructure you don’t need.

---

Pricing: SaaS vs self-hosted math

WunderGraph’s managed cloud pricing isn’t published with explicit tier breakdowns in the available source data. The website directs visitors to a contact-sales flow for enterprise and shows a free tier for getting started. The self-hosted path is Apache-2.0 with no licensing cost.

What self-hosting Cosmo actually costs:

• The full Cosmo stack (router, control plane, studio, schema registry, observability) deploys via Helm chart on Kubernetes [README]
• You need a real Kubernetes cluster — this isn’t a $5 VPS deployment. Minimum realistic infrastructure: a managed K8s service (EKS, GKE, AKS) or a self-managed cluster on Hetzner/Contabo, running at minimum 3 nodes
• Realistic infra cost range: $150–$500/month depending on cloud provider and cluster size, before engineer time for setup and maintenance

The Apollo GraphOS comparison: Apollo GraphOS pricing is not published in the provided sources, so exact numbers aren’t included here to avoid fabrication. The case study signal: SoundCloud reduced costs 30% (from $14K to $9.75K/month) by switching. Acoustic calculated $178K in saved engineering effort — not infrastructure costs, but development work avoided by using Cosmo’s schema management instead of building custom tooling [1]. These figures suggest the ROI exists at significant scale, not at a startup’s first GraphQL endpoint.

Practical math: If your team is paying Apollo GraphOS enterprise rates and running significant query volume, Cosmo self-hosted is likely cheaper by a wide margin. If you’re a three-person startup on Apollo’s free tier evaluating whether to federate, the cost argument doesn’t apply yet — the complexity argument does.

---

Deployment reality check

This is not Activepieces or Gitea where a Compose file on a $10 VPS gets you running in 30 minutes. Cosmo is infrastructure for infrastructure.

What the README actually offers:

• A full-cosmo-docker example for evaluating the full platform locally via Docker Compose
• A full-cosmo-helm chart for production Kubernetes deployment
• A router-simple example for developers who just want to compose and route locally
• The README explicitly targets different examples at: Developer, Architect, Platform Engineer, Decision Maker [README]

That last category — “Decision Maker (e.g., Engineering Manager, CTO)” — is pointed at a sales call, not a quickstart. That’s an honest signal about where the complexity line sits.

What you actually need for production:

• Kubernetes cluster with at least 3 nodes
• PostgreSQL (for the control plane and schema registry)
• ClickHouse (for analytics/observability — this is not a lightweight addition)
• Redis
• NATS (if using event-driven subscriptions)
• An ingress controller and cert management for TLS
• A platform engineer who has done this before, or several days of trial and error

The compliance article [4] is candid about the trade-off: on-prem means your CISO can audit everything and nothing leaves your network, but it also means you own the operational burden entirely.

Where things break:

• ClickHouse is the dependency that surprises people — it’s a column-store analytics database, not trivial to operate
• The Hub feature (schema canvas and governance workflows) is newer and less documented than the core Cosmo stack
• Community size (1,180 stars) means the pool of people who’ve debugged your specific Helm chart issue is small

Realistic setup time for a team with Kubernetes experience: 1–3 days to a working production-grade deployment. Without that experience: weeks, or a managed cloud subscription.

---

Pros and cons

Pros

• Clean Apache-2.0 license, zero feature gating. No enterprise version, no dual licensing, no Fair-code restrictions. The same codebase you self-host is what WunderGraph runs in managed cloud [3][README].
• Genuine on-prem capability. Unlike Apollo GraphOS, the control plane and schema registry can run entirely inside your network. No data leaves unless you choose managed cloud [4].
• Performance benchmarks are architecturally justified. Go-based query planner, AST-JSON result merging, single-flight execution, cache warmer — the engineering choices that produce the 8x latency benchmark are documented and verifiable [website][README].
• Multi-protocol federation. GraphQL, REST, gRPC, and event streams in one supergraph is a real differentiator — Apollo’s equivalent requires more custom work [website].
• MCP integration. Schema exploration and proposal workflows from Cursor/Windsurf without CLI context-switching is a practical developer experience improvement [website].
• Real enterprise validation. On The Beach (4B clicks/month), SoundCloud, Acoustic are named customers with specific metrics — not anonymous testimonials [1].
• No artificial feature tiers in the open-source product. Everything in the repo is available to self-hosters [3].

Cons

• 1,180 GitHub stars. For infrastructure tooling that competes with Apollo (tens of thousands of stars, years of ecosystem), this is a small community. Fewer StackOverflow answers, fewer blog posts from independent users, smaller pool of engineers who’ve operated this before.
• Kubernetes is mandatory for production. This isn’t a tool you hand to a developer who’s never touched K8s. The Docker Compose path is for evaluation, not production [README].
• All available third-party articles are WunderGraph’s own blog. The case studies are credible (named companies, specific numbers), but there are no independent reviews, no community forum threads, no neutral benchmarks in the source material. Caveat emptor on performance claims.
• Hub is new and underspecified. The governance canvas product is positioned as a major differentiator but is labeled as newly launched (“Hub is live 🚀”) with limited independent documentation [website].
• ClickHouse dependency. Adding a column-store analytics database to your infrastructure footprint is non-trivial to operate, scale, and back up [README, inferred from stack].
• Small company. WunderGraph has gone through a product pivot (from BFF SDK to Federation platform). Apollo has the institutional backing of Apollographql.io ecosystem. Betting core API infrastructure on a smaller startup carries longevity risk.
• Not for REST-only or small teams. GraphQL Federation only makes sense when you have multiple backend teams that each own part of a schema. One team, one backend — this is overengineering by definition.

---

Who should use this / who shouldn’t

Use WunderGraph Cosmo if:

• You’re running (or planning) GraphQL Federation across multiple backend teams and you’re tired of Apollo GraphOS pricing or cloud dependency.
• Your compliance team or legal requires fully on-prem API infrastructure with no external cloud dependencies.
• You have a platform engineer who can own Kubernetes-based deployments and isn’t afraid of ClickHouse.
• You want a single, Apache-licensed codebase that you can fork, audit, and extend without commercial agreements.
• You’re currently paying Apollo enterprise rates and the math on self-hosting a K8s cluster is favorable.

Skip it if:

• You’re not doing GraphQL Federation — this tool solves a problem you don’t have.
• You’re a solo developer or two-person startup. The operational overhead doesn’t justify the benefit until you have multiple backend teams.
• Your team doesn’t have Kubernetes experience. The learning curve is steep and the community is small enough that you’ll spend days debugging deployment issues.
• You need large community support, abundant tutorials, and battle-tested StackOverflow coverage — Apollo’s ecosystem is orders of magnitude larger.
• You’re evaluating GraphQL tooling more broadly — consider Hasura for data-layer GraphQL or PostGraphile for Postgres-native approaches if Federation isn’t your specific use case.

---

Alternatives worth considering

• Apollo GraphOS — the incumbent, mature, massive ecosystem, expensive at enterprise scale, requires cloud connectivity for platform features. The obvious comparison.
• Apollo Router (open source) — the router component of Apollo’s stack is Apache-2.0, but schema registry and advanced analytics are cloud-tied. Good if you want Apollo’s query planner with self-hosted routing.
• The Guild’s stack (graphql-mesh, hive) — the open-source GraphQL tooling collective. Hive is their schema registry and observability platform, also open source. Worth evaluating alongside Cosmo.
• Hasura — different category (Postgres-native GraphQL) but often compared. Better fit if your data is primarily relational and you want instant GraphQL without a federation architecture.
• Grafbase — newer federated GraphQL platform, cloud-first.
• Stellate — edge caching and performance layer for GraphQL, not a full federation stack.

For teams evaluating Apollo → open-source migration, the realistic shortlist is WunderGraph Cosmo vs. The Guild’s Hive. Both are Apache-licensed, both offer schema registry + router + observability, and both have real production deployments. Cosmo has stronger performance benchmark claims; Hive has a larger community and longer open-source track record.

---

Bottom line

WunderGraph Cosmo is a technically credible, fully open-source answer to a real problem: Apollo GraphOS is expensive, cloud-dependent, and hard to negotiate with. For engineering teams running federated GraphQL at scale — the On The Beach / SoundCloud tier — the cost and compliance arguments are legitimate, and the performance benchmarks (even unverified by independent sources) are architecturally grounded. The Apache-2.0 license with no feature tiering is genuinely rare in this category.

The honest caution is this: 1,180 GitHub stars for infrastructure tooling suggests a small installed base, the available third-party evidence is almost entirely WunderGraph’s own blog, and the deployment complexity requires real Kubernetes expertise. This is not a tool you evaluate in an afternoon. If you’re at the scale where Apollo GraphOS costs matter and you have the platform engineering capacity to own K8s infrastructure, Cosmo deserves a serious evaluation. If you’re earlier than that, the operational overhead isn’t worth it yet.

For teams that want the benefits of Cosmo without managing the Kubernetes stack themselves, WunderGraph offers managed cloud — and that’s the point where a partner who’s deployed it before (like upready.dev) saves you the most time.

---

Sources

1. Stefan Avram & Brendan Bondurant, WunderGraph Blog — “From Custom Code to Cutting-Edge: On The Beach Adopts WunderGraph Cosmo for GraphQL Federation” (Feb 3, 2025). https://wundergraph.com/blog/cosmo_case_study_on_the_beach
2. Prithwish Nath, WunderGraph Blog — “A Open Source Schema Registry with Schema Checks for Federated GraphQL” (Oct 26, 2023). https://wundergraph.com/blog/a-open-source-schema-registry
3. Jens Neuse, WunderGraph Blog — “How to align Open Source and Enterprise Sales” (Sep 18, 2024). https://wundergraph.com/blog/open_source_and_enterprise_sales
4. Björn Schwenzer, WunderGraph Blog — “How Cosmo meets Compliance Requirements and Saves Onboarding Time” (Nov 20, 2023). https://wundergraph.com/blog/how-cosmo-meets-compliance-requirements

Primary sources:

• GitHub repository and README: https://github.com/wundergraph/cosmo (1,180 stars, Apache-2.0 license)
• Official website: https://wundergraph.com
• Cosmo documentation: https://cosmo-docs.wundergraph.com