Skip to main content
APIScout

Best GraphQL Federation Platforms 2026

·APIScout Team
graphql-federationapollo-federationthe-guild-hivewundergraphcosmographql-gatewaysupergraphgraphql-api
Share:

Why GraphQL Federation Exists

A single GraphQL schema for a large application becomes a maintenance burden: every team's data types and mutations live in one massive schema, every API change requires coordinating across teams, and the single GraphQL server becomes a deployment bottleneck.

GraphQL Federation solves this by composing multiple independent GraphQL subgraph schemas into a single unified supergraph — one API surface, multiple independent services. The users team owns the User type; the products team owns Product; the orders team owns Order. The federation gateway stitches them together automatically.

In 2026, four platforms provide GraphQL federation infrastructure: Apollo Federation (the standard that defined the spec), The Guild's Hive (open-source, MIT-licensed, with strong spec compliance), WunderGraph (visual schema design + managed federation), and Cosmo (open-source router by WunderGraph, composable and fast).

TL;DR

Apollo Federation is the most widely adopted — defined the federation specification that others now implement, largest ecosystem, GraphOS managed service at $99/month. The Guild's Hive is the best open-source alternative — MIT-licensed, Apollo Federation compliant, self-hostable with free cloud tier, and the most active community outside Apollo. WunderGraph provides a visual collaborative schema design experience on top of federation. Cosmo is WunderGraph's high-performance open-source router — a strong self-hosted alternative to Apollo Router.

Key Takeaways

  • Apollo GraphOS starts at $99/month for the Serverless tier (pay-per-operation), with Team plan at $1,700/month. Apollo Router is open-source (Elastic License).
  • GraphQL Hive is MIT-licensed — free to self-host, free cloud tier available, and scores 100% on the Federation audit specification.
  • WunderGraph Cosmo is an open-source (Apache 2.0) federation router with a commercial managed service.
  • Apollo Federation 2 introduced entity interface support, @override directive, and @interfaceObject — significant improvements over Federation 1.
  • Open Federation spec (maintained by The Guild) aims to standardize federation across implementations so routers and subgraphs from different vendors can interoperate.
  • Performance benchmarks (September 2025): Apollo Router and WunderGraph perform similarly at ~900ms average, ~2500ms p95 under load; Hive Gateway is competitive.
  • Self-hosting the router is common — Apollo Router (OSS), Cosmo, and Hive Gateway are all self-hostable, with managed options for the control plane (schema registry, observability).

Pricing Comparison

PlatformFree TierPaid StartingLicense
Apollo GraphOSNo$99/month (Serverless)Router: Elastic
The Guild HiveYes (cloud + self-host)Custom (Enterprise)MIT
WunderGraph CosmoYes (cloud free)Contact salesApache 2.0
Grafbase GatewayYes (self-host)Contact salesOpen-source

Apollo Federation

Best for: Enterprise teams, broadest ecosystem, most mature spec implementation, Apollo Studio analytics

Apollo Federation defined the GraphQL Federation specification — the @key, @extends, @requires, and @external directives that allow subgraphs to share and extend types across services. Apollo Federation 2 (2022+) improved entity resolution, added @interfaceObject, and introduced the @override directive for gradual migration between subgraphs.

Pricing

PlanCostOperations/Month
Serverless$99/month$0.20/million ops
Team$1,700/monthUnlimited
EnterpriseCustomUnlimited + SLAs

Apollo Router (the runtime) is available under the Elastic License — free for internal and non-commercial use, commercial use requires a license.

Subgraph Implementation

// products-subgraph/src/schema.ts
import { buildSubgraphSchema } from "@apollo/subgraph";
import { gql } from "graphql-tag";
import { resolvers } from "./resolvers";

const typeDefs = gql`
  extend schema
    @link(url: "https://specs.apollo.dev/federation/v2.3", import: ["@key", "@external", "@requires", "@provides"])

  type Query {
    product(id: ID!): Product
    products(limit: Int = 20): [Product!]!
  }

  type Product @key(fields: "id") {
    id: ID!
    name: String!
    price: Float!
    description: String
    category: Category!
  }

  type Category {
    id: ID!
    name: String!
    slug: String!
  }
`;

export const schema = buildSubgraphSchema({ typeDefs, resolvers });

// orders-subgraph — extends Product from products-subgraph
const typeDefs = gql`
  extend schema
    @link(url: "https://specs.apollo.dev/federation/v2.3", import: ["@key", "@external"])

  type Order @key(fields: "id") {
    id: ID!
    product: Product!  # Reference to product in products-subgraph
    quantity: Int!
    total: Float!
    status: OrderStatus!
  }

  # Extend the Product type to add order-related data
  type Product @key(fields: "id") {
    id: ID! @external
    orderCount: Int!     # Only orders-subgraph resolves this
  }

  enum OrderStatus {
    PENDING
    PROCESSING
    SHIPPED
    DELIVERED
  }
`;

const resolvers = {
  Product: {
    // This subgraph handles orderCount for Product entities
    __resolveReference: async (reference) => ({
      id: reference.id,
      orderCount: await db.orders.countByProduct(reference.id),
    }),
  },
};

Supergraph Composition

# Rover CLI — compose subgraphs into supergraph
npm install -g @apollo/rover

# rover.yaml
federation_version: =2.3.2
subgraphs:
  products:
    routing_url: https://products-api.example.com/graphql
    schema:
      subgraph_url: https://products-api.example.com/graphql
  orders:
    routing_url: https://orders-api.example.com/graphql
    schema:
      subgraph_url: https://orders-api.example.com/graphql
  users:
    routing_url: https://users-api.example.com/graphql
    schema:
      subgraph_url: https://users-api.example.com/graphql

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

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

When to Choose Apollo Federation

Organizations with existing Apollo Federation subgraphs, teams that need the most mature and feature-complete federation implementation, or enterprises that want GraphOS managed cloud services (schema registry, metrics, Studio analytics dashboard).

The Guild Hive

Best for: Open-source, MIT license, Apollo Federation compliant, self-hostable, cost-conscious teams

GraphQL Hive is the open-source alternative to Apollo GraphOS — a complete GraphQL management platform with schema registry, versioning, analytics, and the Hive Gateway (federation router). The MIT license means you can self-host without licensing restrictions, and the cloud tier includes a free plan.

Pricing

PlanCostFeatures
Hobby (cloud)Free1M operations/month
Pro (cloud)Contact salesUnlimited + SLA
Self-hostedFreeFull features, your infra
EnterpriseCustomManaged + support

Schema Registry

# Hive CLI — publish subgraph schema
npm install -g @graphql-hive/cli

# Publish from CI/CD
hive schema:publish \
  --token $HIVE_TOKEN \
  --service products \
  --url https://products-api.example.com/graphql \
  products-schema.graphql

# Check before publishing (prevents breaking changes)
hive schema:check \
  --token $HIVE_TOKEN \
  --service orders \
  orders-schema.graphql

Hive Gateway Configuration

# gateway.config.yaml — Hive Gateway
sources:
  - name: products
    type: graphql
    endpoint: https://products-api.example.com/graphql
    timeout: 10000

  - name: orders
    type: graphql
    endpoint: https://orders-api.example.com/graphql
    timeout: 10000

  - name: users
    type: graphql
    endpoint: https://users-api.example.com/graphql
    timeout: 10000

cache:
  max: 1000

logging:
  level: info

Self-Hosting with Docker

# docker-compose.yml — Hive self-hosted
version: "3.8"

services:
  hive-app:
    image: ghcr.io/kamilkisiela/graphql-hive/app:latest
    environment:
      - DATABASE_URL=postgresql://hive:password@postgres:5432/hive
      - REDIS_URL=redis://redis:6379

  hive-gateway:
    image: ghcr.io/kamilkisiela/graphql-hive/gateway:latest
    ports:
      - "4000:4000"
    environment:
      - HIVE_TOKEN=your-token
      - HIVE_APP_URL=http://hive-app:3000

When to Choose The Guild Hive

Teams that want Apollo Federation compliance without Apollo's licensing restrictions, organizations that need to self-host the full platform (schema registry + gateway) for compliance or cost reasons, or teams that are cost-sensitive — Hive's MIT license and free tiers provide significant savings over Apollo GraphOS at scale.

WunderGraph Cosmo

Best for: High-performance router, open-source Apache 2.0, visual schema design, modern stack

WunderGraph Cosmo is the federation router and platform from WunderGraph — an Apache 2.0 licensed alternative to Apollo Router with competitive performance benchmarks. The Cosmo platform includes a visual schema design studio (collaborative canvas), schema registry, and analytics. The router itself is open-source.

Cosmo Router Performance

Based on September 2025 benchmarks by Grafbase:

  • Average response time: ~900ms (comparable to Apollo Router)
  • p95: ~2,500ms under load
  • Throughput: Competitive with Apollo Router

Cosmo CLI Setup

# Install WunderGraph CLI
npm install -g wgc

# Initialize a new federated graph
wgc init my-supergraph

# Publish subgraph schema to Cosmo
wgc subgraph publish products \
  --namespace production \
  --schema products.graphql \
  --routing-url https://products-api.example.com/graphql

# Compose and deploy the supergraph
wgc graph deploy my-supergraph

Router Configuration

# cosmo-router.yaml — Cosmo Router configuration
graph:
  token: "${COSMO_GRAPH_TOKEN}"

engine:
  enable_single_flight: true
  execution_plan_cache_size: 10240

traffic_shaping:
  all:
    request_timeout: 60s

rate_limit:
  enabled: true
  strategy: simple_sliding_window
  rate: 1000
  burst: 2000
  period: 1s

telemetry:
  service_name: cosmo-router
  tracing:
    enabled: true

When to Choose Cosmo

Teams that want an open-source (Apache 2.0) federation router with commercial support available, organizations evaluating Apollo alternatives due to licensing or pricing, or teams that want WunderGraph's visual schema design studio for collaborative API development.

Federation Concepts Reference

# Key federation directives (Apollo Federation 2 compatible)

# @key — marks primary key for an entity
type User @key(fields: "id") {
  id: ID!
  email: String!
}

# @external — field defined in another subgraph
type Product @key(fields: "id") {
  id: ID! @external
  # name comes from products-subgraph, not this one
  name: String! @external
  # This subgraph adds inventory data
  stockCount: Int!
}

# @requires — this field needs other fields from entity
type Product @key(fields: "id") {
  id: ID! @external
  weight: Float! @external
  shippingCost: Float! @requires(fields: "weight")
  # Resolver receives weight from products-subgraph
}

# @override — migrate field ownership between subgraphs
type Order @key(fields: "id") {
  id: ID!
  # Gradually migrate 'status' field from old-service to new-service
  status: OrderStatus! @override(from: "old-orders-service")
}

Schema Evolution and Breaking Change Detection

The primary operational risk in federated GraphQL is breaking changes — modifying a subgraph schema in a way that breaks the composed supergraph or client queries. Unlike REST APIs where breaking changes are detected at runtime (404s, changed response shapes), GraphQL breaking changes can be silent: a field removal succeeds at the gateway level but returns null to clients that expected data.

Breaking changes in federation include: removing a field or type, changing a field's type or nullability (adding non-null ! to a previously nullable field), changing an entity's @key fields, and removing @external fields that other subgraphs require with @requires. The federation composition step catches structural incompatibilities — if subgraph A requires field weight from subgraph B via @requires, and subgraph B removes weight, composition fails. But composition doesn't catch all client-facing breaking changes.

Apollo GraphOS includes breaking change detection in the schema check process — rover schema check compares the proposed schema against production operation traffic and flags fields that appear in client operations being removed. This is the most complete protection: it guards against changes that break real clients, not just hypothetical compatibility. Hive offers the same capability in its schema check command — published schema changes are validated against recorded operation traffic.

The @deprecated directive is the correct migration pattern for non-breaking field evolution:

type Product @key(fields: "id") {
  id: ID!
  price: Float! @deprecated(reason: "Use priceInCents for precision")
  priceInCents: Int!  # New field — add first, migrate clients, then remove old field
}

The @override directive (Apollo Federation 2) allows gradual migration of field ownership between subgraphs without downtime. If you're moving the status field from orders-v1 to orders-v2, you add status to orders-v2 with @override(from: "orders-v1"). Both subgraphs handle the field during the transition period; once all traffic is on orders-v2, you remove status from orders-v1. This is the recommended pattern for re-platforming subgraphs without a flag day.

Schema registry tooling (Apollo GraphOS, Hive) stores schema history and operation records, making safe evolution possible. Teams without a schema registry — composing locally and deploying without checking against operation traffic — are operating without a safety net and will eventually ship a breaking change.

Distributed Tracing Across Subgraphs

Debugging federated GraphQL queries is significantly harder than debugging monolithic GraphQL. A single client query may fan out to three or four subgraphs, and a slow response could originate in any of them. Without distributed tracing, identifying the bottleneck requires inferring from response times rather than observing them directly.

Apollo Router and Cosmo both emit OpenTelemetry traces with spans for query planning, subgraph fetch, and entity resolution. A trace for a federated query looks like: gateway receives request → query plan generated → subgraph A fetch (User type) → subgraph B fetch (Product type, using user.id from A's response) → subgraph C fetch (inventory, using product.id from B's response) → response assembled. Each subgraph span shows network time + execution time separately, making it immediately clear whether latency is in the gateway, network, or subgraph execution.

Query planning cost is a non-obvious latency contributor. The gateway analyzes every incoming query against the supergraph schema and produces an execution plan — which subgraphs to query, in what order, with what variables. Complex queries with deep entity chains produce expensive query plans. Apollo Router caches query plans by query signature; a cold cache (after deployment) produces higher initial latency until the cache warms. Monitoring query plan cache hit rate is a useful indicator of optimization opportunities.

N+1 problems in federation occur when entity resolution triggers one subgraph request per entity instead of a batch. Properly implemented @key resolvers handle arrays of references in one batch request; improperly implemented resolvers call the subgraph once per entity, producing O(n) subgraph requests for O(n) entities. DataLoader (or its framework equivalent) is the solution in subgraph resolvers that fetch from databases; for subgraph-to-subgraph entity resolution, federation itself handles batching at the gateway level when entity resolvers accept arrays. Checking the trace span count for entity resolution spans quickly identifies N+1 issues — you'll see 50 spans where there should be 1.

Both Apollo GraphOS and Hive provide analytics dashboards showing operation frequency, error rates, and latency by operation and field. Field-level analytics (which fields are actually queried) drives safe schema cleanup — fields with zero query traffic over 30 days can be safely deprecated and eventually removed without client impact.

Decision Framework

ScenarioRecommended
Enterprise, GraphOS analyticsApollo GraphOS
Open-source, self-hostedThe Guild Hive
MIT license requiredThe Guild Hive
High-performance OSS routerCosmo (Apache 2.0)
Visual schema designWunderGraph
Apollo Federation complianceHive or Apollo
Cost-sensitiveHive (free self-host)
New project, Apollo ecosystemApollo GraphOS

Verdict

Apollo Federation remains the ecosystem standard — the widest adoption, most tooling, and the specification that all other implementations target. Apollo GraphOS at $99-$1,700/month is the trade-off for managed schema registry and analytics.

The Guild Hive is the most compelling alternative — MIT licensed, Apollo Federation 2 compliant, free to self-host, and actively developed by the team behind some of the most-used GraphQL tooling (graphql-code-generator, graphql-yoga, envelop). For cost-conscious teams, the savings over Apollo GraphOS are significant.

Cosmo is the performance-focused open-source router — if you want an Apache 2.0 licensed router with benchmark performance comparable to Apollo Router, Cosmo is the answer.

The federation tooling ecosystem continues to mature. The Open Federation Specification (maintained by The Guild alongside Hive development) aims to ensure that subgraphs from one vendor's tools are fully composable with routers from another — breaking the lock-in between subgraph implementation and gateway choice that currently makes switching between Apollo, Hive, and Cosmo more work than it should be. Teams evaluating federation infrastructure in 2026 should consider how tightly their subgraph implementation is coupled to their gateway choice, and whether the Open Federation roadmap affects their long-term vendor flexibility. Both Hive and Cosmo have committed to Open Federation compliance; Apollo's Federation 2 specification is the current de facto standard that all implementations target.

For teams considering federation for the first time: federation adds operational complexity that is only justified when you have multiple teams owning separate GraphQL subgraphs, or when a monolithic schema has become a coordination bottleneck. A single-team application with one GraphQL service has no need for federation — a well-organized monolithic schema with good module separation serves the same purpose without the gateway overhead, query plan complexity, and distributed tracing requirements that federation introduces. The right time to adopt federation is when the organizational structure (multiple teams, separate deployments, different release cycles) actually maps to the federated model — not as a preemptive architecture decision for future scale that hasn't materialized yet.

Compare GraphQL federation platform pricing, spec compliance, and schema registry features at APIScout — find the right federation infrastructure for your GraphQL supergraph.

Related: GraphQL Client Patterns for Production Apps, GraphQL vs REST: When to Use Each in 2026, REST vs GraphQL vs gRPC: API Protocol Guide 2026

The API Integration Checklist (Free PDF)

Step-by-step checklist: auth setup, rate limit handling, error codes, SDK evaluation, and pricing comparison for 50+ APIs. Used by 200+ developers.

Join 200+ developers. Unsubscribe in one click.