Apollo Router vs Hive Gateway vs WunderGraph: GraphQL Federation 2026

TL;DR

GraphQL Federation allows multiple teams to own their subgraphs — each team deploys their own GraphQL service, and a router composes them into one unified API. Apollo Router (Rust) is the production standard — fastest, most feature-rich, and backed by Apollo (the company that defined the Federation spec). Hive Gateway is the open-source alternative to Apollo — implements Federation v2, self-hostable with no usage limits, part of the GraphQL Hive ecosystem. WunderGraph takes a broader approach — not just GraphQL federation but a full API management layer supporting REST, GraphQL, gRPC, and subscriptions in a unified gateway. For maximum performance and Federation spec compliance: Apollo Router. For open-source Federation without Apollo's pricing: Hive Gateway. For multi-protocol API composition beyond GraphQL: WunderGraph.

Key Takeaways

• Apollo Router is written in Rust — 8-10x faster throughput than Apollo Gateway (Node.js)
• Hive Gateway GitHub stars: ~1k — newer but growing as Apollo's paid features push teams to alternatives
• WunderGraph supports REST + GraphQL + gRPC — it's an API gateway, not just GraphQL federation
• Apollo Federation v2 spec is open — Hive Gateway, WunderGraph, and others implement it
• Apollo Router's Enterprise features require paid plan — persisted queries, JWT auth, response caching
• Hive Gateway is fully free — schema registry (GraphQL Hive) has a generous free tier
• All three support subscriptions — real-time data via WebSocket or SSE

What GraphQL Federation Solves

Without Federation:

Option 1: One monolithic GraphQL schema → all teams blocked on each other
Option 2: Multiple GraphQL services → clients make multiple requests

With Federation:

Team A: Users subgraph (users.graphql) → deployed independently
Team B: Products subgraph (products.graphql) → deployed independently
Team C: Orders subgraph (orders.graphql) → deployed independently

Router: Composes all subgraphs into one unified schema
Client: Makes one request → router distributes to correct subgraphs

Apollo Router: The Rust-Powered Standard

Apollo Router is a high-performance GraphQL Federation router written in Rust. It replaced Apollo Gateway (Node.js) as the recommended federation router for production.

Installation

# Via install script
curl -sSL https://router.apollo.dev/download/nix/latest | sh

# Docker
docker pull ghcr.io/apollographql/router:latest

# Configuration file
cat > router.yaml << EOF
supergraph:
  path: /graphql
  listen: 0.0.0.0:4000

sandbox:
  enabled: true

health_check:
  path: /health

cors:
  origins:
    - https://yourapp.com
    - http://localhost:3000
EOF

Supergraph Schema Composition

# Install Rover CLI
npm install -g @apollo/rover

# Define subgraph configurations
cat > supergraph.yaml << EOF
federation_version: =2.5.0

subgraphs:
  users:
    routing_url: http://users-service:4001/graphql
    schema:
      subgraph_url: http://users-service:4001/graphql

  products:
    routing_url: http://products-service:4002/graphql
    schema:
      subgraph_url: http://products-service:4002/graphql

  orders:
    routing_url: http://orders-service:4003/graphql
    schema:
      subgraph_url: http://orders-service:4003/graphql
EOF

# Compose supergraph schema
rover supergraph compose --config supergraph.yaml > supergraph.graphql

# Start router with composed schema
./router --supergraph supergraph.graphql --config router.yaml

Subgraph Implementation (Node.js)

// users-service/src/schema.ts
import { buildSubgraphSchema } from "@apollo/subgraph";
import { gql } from "graphql-tag";
import { ApolloServer } from "@apollo/server";
import { startStandaloneServer } from "@apollo/server/standalone";

const typeDefs = gql`
  # Federation directive — this type can be referenced by other subgraphs
  type User @key(fields: "id") {
    id: ID!
    name: String!
    email: String!
    # This field is resolved by the orders subgraph
    orders: [Order!]!
  }

  # Stub type from another subgraph
  type Order @key(fields: "id", resolvable: false) {
    id: ID!
  }

  type Query {
    user(id: ID!): User
    users: [User!]!
    me: User
  }
`;

const resolvers = {
  User: {
    // Reference resolver — called when orders subgraph needs User data
    __resolveReference(user: { id: string }) {
      return findUserById(user.id);
    },
  },
  Query: {
    user: (_, { id }) => findUserById(id),
    users: () => getAllUsers(),
    me: (_, __, { userId }) => findUserById(userId),
  },
};

const server = new ApolloServer({
  schema: buildSubgraphSchema({ typeDefs, resolvers }),
});

await startStandaloneServer(server, { listen: { port: 4001 } });

Apollo Router Configuration (router.yaml)

# router.yaml — Apollo Router configuration
supergraph:
  path: /graphql
  listen: 0.0.0.0:4000

# Authentication
authentication:
  router:
    jwt:
      jwks:
        - url: https://your-auth.example.com/.well-known/jwks.json
          issuer: https://your-auth.example.com/

# Authorization — coprocessor or Rego policies
authorization:
  directives:
    enabled: true

# Caching (Enterprise)
preview_entity_cache:
  enabled: true
  subgraphs:
    products:
      enabled: true
      ttl: 60s

# Traffic shaping
traffic_shaping:
  router:
    global_rate_limit:
      capacity: 1000
      interval: 1s
  all:
    timeout: 30s

# Telemetry
telemetry:
  exporters:
    metrics:
      prometheus:
        enabled: true
        listen: 0.0.0.0:9090
        path: /metrics

Hive Gateway: Open-Source Federation

Hive Gateway is part of the GraphQL Hive ecosystem — an open-source schema registry and analytics platform. The gateway itself is free and open-source with no usage limits.

Installation

npm install @graphql-hive/gateway

# Or Docker
docker pull ghcr.io/graphql-hive/gateway:latest

Gateway Configuration

// gateway.config.ts
import { defineConfig } from "@graphql-hive/gateway";

export const gatewayConfig = defineConfig({
  supergraph: {
    type: "hive",
    // Pull supergraph from Hive schema registry
    endpoint: "https://cdn.graphql-hive.com/your-endpoint/supergraph",
    key: process.env.HIVE_CDN_KEY!,
    // Or use a static file:
    // type: "file",
    // path: "./supergraph.graphql",
  },

  // Runtime configuration
  port: 4000,

  // Authentication
  jwt: {
    lookupLocations: ["authorization-header"],
    tokenSeparator: "Bearer ",
    jwksEndpoint: "https://your-auth.example.com/.well-known/jwks.json",
    algorithms: ["RS256"],
    forward: {
      payload: true,  // Forward JWT claims to subgraphs
    },
  },

  // Response caching
  cache: {
    enabled: true,
    store: "memory",
    ttl: 60,
  },

  // Persisted queries
  persistedDocuments: {
    type: "hive",
    endpoint: "https://cdn.graphql-hive.com/apps/your-app-id/persisted-documents",
    key: process.env.HIVE_CDN_KEY!,
  },
});

Starting Hive Gateway

// gateway.ts
import { createGatewayRuntime } from "@graphql-hive/gateway";
import { gatewayConfig } from "./gateway.config";

const gateway = createGatewayRuntime(gatewayConfig);

// As standalone server
import { createServer } from "http";

const server = createServer(async (req, res) => {
  const response = await gateway.handleNodeRequest(req, { res });
  response.headers.forEach((value, key) => res.setHeader(key, value));
  res.writeHead(response.status);
  res.end(await response.text());
});

server.listen(4000);

Hive Schema Registry Integration

# Publish subgraph schemas to Hive
npm install -g @graphql-hive/cli

# Publish users subgraph schema
hive schema:publish \
  --registry.endpoint https://app.graphql-hive.com/graphql \
  --registry.accessToken $HIVE_TOKEN \
  --service users \
  --url http://users-service:4001/graphql \
  users-schema.graphql

# Hive checks for breaking changes before each publish
hive schema:check \
  --service users \
  users-schema.graphql

WunderGraph: Multi-Protocol API Gateway

WunderGraph composes REST APIs, GraphQL APIs, and gRPC services into a unified GraphQL interface. It generates type-safe clients automatically.

Installation

npm install @wundergraph/sdk
npx wundergraph init  # Initialize project

WunderGraph Configuration

// wundergraph.config.ts
import {
  configureWunderGraphApplication,
  cors,
  introspect,
  templates,
} from "@wundergraph/sdk";

// Introspect your services (REST, GraphQL, gRPC)
const usersService = introspect.graphql({
  apiNamespace: "users",
  url: "http://users-service:4001/graphql",
});

const productsAPI = introspect.openApiV2({
  apiNamespace: "products",
  source: {
    kind: "file",
    filePath: "./apis/products-openapi.yaml",
  },
});

const ordersService = introspect.graphql({
  apiNamespace: "orders",
  url: "http://orders-service:4003/graphql",
});

export default configureWunderGraphApplication({
  apis: [usersService, productsAPI, ordersService],

  server: {
    hooks: {
      queries: {
        // TypeScript hooks for request/response transformation
        UserWithOrders: {
          preResolve: async ({ user, clientRequest }) => {
            // Inject auth context
            return { user };
          },
        },
      },
    },
  },

  codeGenerators: [
    {
      templates: [
        // Generate TypeScript client
        templates.typescript.client,
        // Generate React hooks
        templates.typescript.reactQuery,
      ],
    },
  ],
});

Auto-Generated Type-Safe Client

// Generated by WunderGraph — fully type-safe
import { createClient } from "../generated/client";

const client = createClient({
  baseURL: "http://localhost:9991",
});

// Query across multiple APIs — type-safe
const { data, error } = await client.query({
  operationName: "UserWithOrdersAndProducts",
  input: { userId: "123" },
});

// data is fully typed:
// data.users_user → from GraphQL users service
// data.products_getProduct → from REST products API
// data.orders_userOrders → from GraphQL orders service

Feature Comparison

Production Performance and Caching Architecture

Apollo Router's Rust implementation delivers measurable throughput advantages at scale — benchmarks from the Apollo team show 8-10x higher requests per second compared to Apollo Gateway (Node.js) under the same load. For teams running federation at millions of requests per hour, this translates directly to infrastructure cost savings. However, the performance ceiling for most teams is determined not by the router's throughput but by subgraph latency — a router that queries four subgraphs with 50ms average latency will still take 50ms+ regardless of router overhead. Caching strategy matters more than router throughput for most production workloads. Apollo Router's entity cache (Enterprise) caches subgraph resolver results by entity key, meaning repeated requests for the same entities skip subgraph network calls entirely. Hive Gateway provides free response caching at the operation level — caching full query results for a configurable TTL — which is simpler to configure but less granular than entity-level caching.

Security Considerations for Federation Gateways

Federated GraphQL gateways introduce a unique security surface: the router is a public-facing service that composes requests to internal subgraphs, creating both an external attack surface and an internal trust boundary. Apollo Router supports JWT authentication via JWKS endpoints, automatically forwarding verified claims to subgraphs via request headers — subgraphs can then trust the forwarded identity without re-verifying tokens. Hive Gateway implements the same JWT forwarding pattern. The critical security practice for all three gateways is ensuring subgraphs are not publicly accessible — they should only accept requests from the router's IP range or require a shared secret in headers. Persisted queries (operation allowlisting) limit the gateway to pre-approved GraphQL operations, preventing exploratory attacks using arbitrary queries. Apollo Router requires an Enterprise plan for persisted queries; Hive Gateway includes this feature in its free self-hosted version.

Schema Registry and Breaking Change Detection

Schema evolution in a federated system requires tooling to detect when a subgraph change would break existing clients. Apollo Studio provides automated breaking change detection when you publish subgraph schemas — flagging removed fields, changed argument types, and type incompatibilities before deployment. GraphQL Hive offers the same schema check functionality in its open-source schema registry, with Slack and GitHub PR integration for breaking change notifications. WunderGraph's approach differs: it introspects APIs at configuration time and generates typed clients, so breaking changes surface as TypeScript compile errors in your application code rather than schema registry alerts. For teams running multiple subgraphs with multiple development teams, the schema registry with automated checks is essential infrastructure — without it, one team's subgraph update can break another team's clients in production silently.

Self-Hosting vs Managed Service Economics

All three gateways can be self-hosted, but the operational overhead differs significantly. Apollo Router self-hosted is a single stateless binary (or Docker container) that scales horizontally behind a load balancer — no database required, configuration via YAML file, telemetry via Prometheus or OTLP. This is genuinely simple to operate. Hive Gateway is a Node.js service that integrates with the Hive CDN for schema distribution — you can run multiple instances behind a load balancer and the schema is fetched from Hive's CDN at startup, eliminating the need to distribute schema files during deployment. WunderGraph requires more infrastructure: the Engine is the gateway, but the full DX requires running code generation as part of your build process and deploying the generated API layer alongside the gateway. For resource-constrained teams, Apollo Router self-hosted or Hive Gateway are operationally simpler than WunderGraph's full platform.

TypeScript Integration and Developer Experience

The developer experience gap between these gateways is most visible during local development. Apollo Router requires running a Rust binary alongside your Node.js subgraphs — easy with Docker Compose but adds complexity compared to a Node.js-only stack. Hive Gateway is a Node.js process, making it natural to run alongside subgraphs in a monorepo with a single npm run dev command. WunderGraph's code generation produces fully typed React Query hooks and a TypeScript client from your API composition configuration — the resulting developer experience for frontend teams is excellent, with type errors for any API call that doesn't match the generated schema. For teams where the gateway is maintained by a platform team and subgraphs by product teams, Apollo Router's stability and documentation make it the lower-risk choice despite the Rust dependency.

When to Use Each

Choose Apollo Router if:

• Performance is critical — Rust vs Node.js is measurable at scale
• You're already invested in the Apollo ecosystem (Apollo Studio, Apollo Client)
• Federation v2 spec compliance and the most mature implementation matters
• You can afford or justify Apollo's enterprise features (or stay on the free tier)

Choose Hive Gateway if:

• You want open-source Federation without usage limits or paid features
• The GraphQL Hive schema registry fits your workflow
• You're moving away from Apollo's proprietary tooling
• Cost predictability matters (self-hosted, no per-operation charges)

Choose WunderGraph if:

• Your API landscape includes REST, GraphQL, and gRPC (not just GraphQL)
• Automatic type-safe client generation is a priority
• You want a full API management solution, not just a federation router
• Your team values the generated-client developer experience

Methodology

Data sourced from GitHub repositories (star counts as of February 2026), official performance benchmarks from Apollo Router blog, federation spec documentation at apollo.dev, and community comparisons on Twitter/X and HackerNews. Feature availability verified against official documentation.

Related: Apollo Client vs URQL for GraphQL client comparison, or Portkey vs LiteLLM vs OpenRouter for AI API gateways with similar routing patterns.

See also: Grafbase vs Hasura vs PostGraphile and tRPC vs GraphQL: API Layer 2026