Apollo Router vs Hive Gateway vs WunderGraph: GraphQL Gateway 2026
TL;DR
Choose Apollo Router when Apollo Federation and GraphOS are the center of the operating model. Choose Hive Gateway when you want a gateway that can run as a standalone binary, Docker image, or JavaScript package and fits a TypeScript-oriented platform. Evaluate WunderGraph through Cosmo, its current federation and governance product surface, rather than through old SDK examples. Do not rank the routers by speed without a controlled workload and reproducible results.
Key Takeaways
- The primary decision is the operating model: dedicated routing runtime, JavaScript-integrated gateway, or Cosmo federation/governance stack.
- Hosted control-plane pricing and self-hosted software licenses belong in separate rows.
- Repository and npm counters are dated interest and distribution context, not installations or production traffic.
- Validate composition, schema delivery, authentication, authorization, observability, failure handling, and rollback with your own supergraph.
- Keep legacy package availability separate from current product direction.
At-a-glance
| Decision area | Apollo Router | Hive Gateway | WunderGraph Cosmo |
|---|---|---|---|
| Current role | Dedicated federation routing runtime | Gateway deployable through several runtime forms | Federation routing, registry, and governance product surface |
| Deployment posture | Router process or container | Binary, container, or JavaScript integration | Cosmo router and control-plane workflow |
| Control plane | Apollo GraphOS | GraphQL Hive | Cosmo |
| License signal | Elastic License 2.0 | MIT | Apache-2.0 in the selected project record |
| Evaluation priority | Federation compatibility and GraphOS workflow | Runtime fit and TypeScript integration | Registry, routing, governance, and migration from legacy WunderGraph artifacts |
Comparison Matrix
Apollo Router
Apollo Router is a dedicated federation routing runtime. Teams already using Apollo Federation and GraphOS can keep schema composition, checks, routing, and platform operations in one vendor ecosystem. The current router docs should be the reference for supported configuration, telemetry, authentication, and deployment behavior.
Hive Gateway
Hive Gateway 2.11.2 documents deployment as a standalone binary, Docker container, and JavaScript package across named runtimes. That flexibility matters when the gateway must fit an existing Node.js or TypeScript service platform. Use the current gateway docs to verify the API and deployment form you intend to operate.
WunderGraph Cosmo
WunderGraph’s current surface is Cosmo, focused on federation/governance and routing. Evaluate the current product and its router rather than carrying forward old multi-protocol snippets. The WunderGraph product site is the starting point for current positioning and documentation.
Pricing and entitlements
Apollo publishes Free, Developer, Standard, and Enterprise GraphOS plans. Hive publishes a separate usage-based platform grid. Cosmo has its own current product terms. Hosted control-plane plans meter different platform activities, while router binaries and containers introduce self-hosted software and infrastructure responsibilities.
Check same-day entitlement rows before purchase. Schema checks, operation metrics, registry access, add-ons, support, and routing infrastructure can be priced or packaged differently. A shared feature name does not prove equivalent entitlement or cost.
Release, package, and repository context
Current release records at the evidence point identified Apollo Router v2.17.0, Hive Gateway 2.11.2, and Cosmo Router router@0.342.0. A legacy npm package remained at 0.184.2, but that artifact is not the release identity of current Cosmo.
At access time, GitHub reported Apollo Router at 970 stars/341 forks, Hive Gateway at 117/41, and Cosmo at 1,253/254. For 2026-08-17 through 2026-08-23, npm recorded 36,212 Hive Gateway distributions and 2,588 distributions for the legacy WunderGraph package. These dated counters are not installations, request volume, reliability, or a ranking.
License boundaries
The selected Apollo Router license record states Elastic License 2.0. Hive Gateway is identified as MIT. Cosmo and the selected legacy package record report Apache-2.0. Review the exact router, control-plane, enterprise, plugin, and deployment artifacts that your architecture will use; one product family can contain different terms.
Federation and runtime fit
The current router docs, current gateway docs, and Cosmo’s federation/governance positioning support a narrower comparison than older “API gateway” tables.
Test these interfaces with a representative supergraph:
- Composition and schema validation for the directives you use.
- Schema delivery from CI or a registry to the running router.
- Authentication, claim propagation, and authorization failures.
- Timeouts, retries, traffic shaping, and subgraph degradation.
- Persisted operations and cache behavior where documented for your plan.
- Tracing, metrics, logs, and correlation across router and subgraphs.
- Rollback of both schema and router configuration.
A TypeScript integration can be convenient, but it does not remove the need to test process isolation, startup behavior, memory, and failure recovery.
Performance and reliability
There is no reproducible benchmark receipt for a universal throughput, latency, or cost ranking. A useful test fixes router versions, configuration, schema, queries, subgraphs, runtime, hardware, region, warmup, concurrency, repetitions, and raw output. Compare p50, p95, p99, errors, CPU, memory, and recovery behavior under the same defined workload.
Apollo’s status API reported All Systems Operational at the evidence point. The Apollo Router, Hive Gateway, and Cosmo repositories reported archived=false and had current releases. This is a point-in-time observation, not a long-term availability or support guarantee.
Migration Notes
For an existing federation gateway, migrate in controlled stages:
- Freeze a representative supergraph schema and query corpus.
- Record current authentication, authorization, headers, timeouts, retries, and telemetry behavior.
- Run the candidate router against non-production subgraphs.
- Replay the same query corpus and compare results and error shapes.
- Exercise schema publication, composition failure, and rollback.
- Send a small production traffic slice only after observability and rollback are proven.
If the current system uses older WunderGraph SDK behavior, inventory each generated client, hook, REST or RPC integration, and build step separately. Do not assume Cosmo replaces those application-level interfaces.
Methodology
This refresh uses current first-party pricing, docs, repository metadata, release records, status data, and dated npm distributions accessed on 2026-08-24. It separates router runtime, hosted control plane, package artifact, and product direction. Versions, entitlements, status, and counters require a fresh check before publication or purchase.
Source-backed FAQ
Which gateway fits a TypeScript platform?
Hive Gateway deserves the first prototype because its documented deployment forms include JavaScript integration. The decision still depends on federation compatibility, operational isolation, observability, and failure behavior.
Does Apollo Router automatically win for Apollo Federation?
It has the closest product alignment with Apollo Federation and GraphOS, but operational fit still depends on your schema workflow, controls, infrastructure, and commercial requirements.
Is old WunderGraph code a Cosmo migration path?
Not automatically. Cosmo is the current routing and governance surface. Inventory old application-generation and multi-protocol behavior as a separate migration scope.