# Orbital vs GraphQL > Where GraphQL and Orbital overlap, where they do not, and how to choose between them - schema, resolvers, federation and the cost of keeping them in step. Source: https://orbitalhq.com/compare/graphql Compare # **Orbital**vsGraphQL GraphQL unifies an application API. **Orbital connects the systems, streams and data products behind the enterprise.** Both can compose data for request/response APIs, and for that job GraphQL is excellent - it was designed for exactly it, the tooling is mature, and a great many teams should keep using it. Orbital solves a wider problem: a semantic execution layer across APIs, databases, event streams and batch workloads, where the systems are heterogeneous, the teams are independent, and the contracts keep moving. This page is about where the two overlap and where they do not. If you are replacing an integration platform rather than drawing a boundary, [the MuleSoft comparison](/compare/mulesoft) is the more useful one. [See where they overlap](#architecture)[Use both together](#together) ### GraphQL Clients query one composed schema, which resolves against the services behind it. Clients - Web app - Mobile app The graph Composed GraphQL schema Resolvers and subgraphs, composed into one schema. Services - Service APIsvia resolvers - SubgraphsGraphQL services ### Orbital Applications, agents, streams and batch jobs query one model of meaning across the estate. Consumers - Applicationsincluding a GraphQL API - AI agentsover MCP - Stream consumerswebsockets, topics - Batch and reporting The layer Orbital semantic runtime One model of meaning, planned per query. Reaches - REST and gRPC - Databases - Kafka topics - Object storageand files Two correct pictures of two different scopes. The graph composes an API for clients; the semantic layer composes meaning across an estate - and an existing GraphQL API is one of the consumers it can sit behind. Scope ## Different tools, **different scopes** These overlap in one place and diverge everywhere else. The third card is not a courtesy - keeping an existing graph is usually the right answer. - [1 ### Application API composition One typed endpoint, clients asking for the fields they need, no over-fetching. This is GraphQL’s problem, and it solves it well - Orbital can do it too, and is not obviously better at it. Compare the architectures](#architecture) - [2 ### Enterprise integration Databases, message queues, gRPC services, files and third-party APIs, feeding streams and batch jobs as well as request/response. This is where the two stop overlapping. Compare by workload](#workloads) - [3 ### Use them together Keep the graph as the application-facing contract and let Orbital do the integration behind it. Adopting Orbital does not mean removing a GraphQL API you already have. See the architecture](#together) Architecture ## Where the two **actually differ** It is worth separating the GraphQL _specification_ from the ecosystem around it. The specification defines queries and mutations as stateless and subscriptions as stateful; durable event processing, change data capture, ETL and cross-protocol integration are normally supplied by other systems. Almost anything can be built around the protocol given resolvers, middleware or a gateway. The useful question is not whether it is possible but what it takes - which is what these four dimensions are about. Who is asking, and how much say do they get over the shape of the answer? Orbital #### A schema declared per consumer Consumer Its own target shape Semantic model A consumer describes the model it wants back - its own field names, its own structure, its own format - and Orbital maps the estate onto it. Two consumers can hold genuinely different models of the same data, in different serialisation formats, without either being canonical. GraphQL #### Fields selected from a shared schema Client Query Composed schema A client selects the fields it needs from the schema the graph publishes, which is exactly the over-fetching problem GraphQL was built to fix, and it fixes it cleanly. The shape available is the shape the composed schema defines. Serving a consumer a different model means adding it to that schema or transforming outside the graph. Compare by workload ## The same job, **done both ways** Three workloads, compared as work rather than as capabilities. The first is a deliberately close comparison and Orbital does not win it. The requirement A web and a mobile client need one typed endpoint that composes customer, order and product data from three services, without over-fetching. Systems involved - Customers API - Orders API - Products API - Two clients Orbital GraphQL What you build Semantic types on the three specifications, and a query per consumer describing the response it wants. A schema for the composed graph and resolvers for each field, or a subgraph per service with a composition step over them. Effort Low. This is well inside what Orbital is for, and there is nothing clever about it. Low. This is the problem GraphQL was designed for, and the tooling, tracing and client libraries around it are excellent. Honest assessment No meaningful advantage. If this is the whole of the requirement, the deciding factors are your team’s existing skills and tooling - not this page. A very good fit. A team already fluent in GraphQL should expect to move faster here than with anything they have to learn first. What you build Orbital Semantic types on the three specifications, and a query per consumer describing the response it wants. GraphQL A schema for the composed graph and resolvers for each field, or a subgraph per service with a composition step over them. Effort Orbital Low. This is well inside what Orbital is for, and there is nothing clever about it. GraphQL Low. This is the problem GraphQL was designed for, and the tooling, tracing and client libraries around it are excellent. Honest assessment Orbital No meaningful advantage. If this is the whole of the requirement, the deciding factors are your team’s existing skills and tooling - not this page. GraphQL A very good fit. A team already fluent in GraphQL should expect to move faster here than with anything they have to learn first. The decision ## Three questions that **settle it** Technologies, consumers and teams. Answer these three honestly about your own estate and the rest of this page is confirmation. 1. 01 ### How many technologies are involved? The single best predictor of which side of the line you are on. Count the things that are not HTTP services. Orbital Read natively OpenAPI · Avro · SQL · Kafka Semantic model API descriptions, Protobuf and Avro schemas, database schemas and streaming sources are all first-class inputs. Adding one is describing what its fields mean. GraphQL Reached through resolvers Any system Resolver or connector Graph Anything can be brought into a graph, and connector tooling has made much of it declarative. It is still an integration somebody owns and maintains in front of each system. 2. 02 ### How many consumers are involved? One consumer, or five with genuinely different models and formats? The answer changes what "the schema" even means. Orbital A model per consumer Consumer A Consumer B Semantic model Each consumer declares the model and format it wants - JSON, CSV, Avro, Protobuf - and none of them is canonical. Nothing has to agree with anything else. GraphQL Fields from one composed schema Every client Composed schema Clients select what they need from a shared schema, which is precisely the right answer when they are all applications. It becomes a constraint when they are not. 3. 03 ### How many teams are involved? Independent ownership is where the difference is most often misstated. Federation is a real answer to it - the question is what it asks of everyone. Orbital Contracts that never have to merge Team A Team B Shared meaning Domains publish and evolve their own contracts. The agreement between them is about what fields mean, not about how their schemas fit together. GraphQL Subgraphs that have to compose Subgraph A Subgraph B Supergraph Federation supports independently defined subgraphs. Composition is the shared obligation: conflicting definitions can prevent a supergraph from being composed. Coexistence ## Use Orbital **and** GraphQL Adopting Orbital does not mean removing a GraphQL API you already have, and in most estates it should not. The two arrangements below are both common, and the first is the more common by a distance. ### Orbital behind the graph The graph stays the application-facing contract; its resolvers stop being an integration layer. Clients - Web and mobileunchanged - Existing GraphQL APIstill the contract Behind it Orbital semantic runtime Resolvers ask Orbital, not six services each. Reaches - REST and gRPC - Databases - Kafka topics ### Orbital in front of the graph New consumers the graph was never meant to serve read the estate - including the graph itself. Consumers - AI agentsover MCP - Stream consumers - Batch and reporting The layer Orbital semantic runtime The graph is one source among several. Reaches - Existing GraphQL APIunchanged - Databases - Kafka topics 2. 1 ### Keep the graph It stays the application-facing contract. Web and mobile clients are not touched, and nothing about the schema they query changes. 3. 2 ### Model behind it Describe what the systems the resolvers call actually mean, in Taxi. This is additive: the resolvers keep working while it happens. 4. 3 ### Move the integration Resolvers that fan out across six services ask Orbital once instead. The graph gets simpler; its contract does not change. 5. 4 ### Serve what the graph does not Streams, batch, agents and non-JSON consumers come off the same model - without adding any of them to the composed schema. [Talk through a coexistence plan](/docs) Decision guide ## When each one is **the right answer** There is a large set of problems where GraphQL is the better choice and this page would be wrong to pretend otherwise. - ### Choose GraphQL when… - The primary problem is a typed API for application clients, and over-fetching is the thing you are solving. - Most of the integration logic already sits behind resolvers or subgraphs and is working. - A composed graph is the contract you want teams to agree on, and federation is doing that job well. - Your team is fluent in the ecosystem - the tooling, tracing and client libraries are a real advantage and they are not free to replace. - ### Choose Orbital when… - The problem spans protocols and systems: databases, queues, gRPC, files and third-party APIs, not just HTTP services. - Streaming, batch, change data capture or cross-system actions are first-class requirements rather than edges. - Consumers need different models and formats of the same data, and some of them are not JSON. - Independent teams need to evolve contracts without a composition step that everyone has to stay compatible with. - ### Use both when… - GraphQL is already the application-facing API and there is no reason to change what clients query. - The resolvers behind it have quietly become an integration layer nobody set out to build. - New consumers - agents, streams, partner feeds - need the same data in shapes the graph was never meant to serve. - Existing GraphQL investment should stay intact, which is usually the right call. Detailed comparison ## The **distinctions that matter** Four states rather than two, because on this page a yes/no answer would nearly always be the wrong one: almost anything can be built around GraphQL, and what a reader needs to know is what it would take. - NativePart of the runtime. Nothing else to stand up. - SupportedA first-class capability, configured rather than built. - Requires extensionAchievable with additional code, tooling or infrastructure. - Not the intended useOutside what the technology set out to solve. ### Primary purpose Orbital GraphQL What the technology is for Native· OrbitalA semantic execution layer across an estate of heterogeneous systems. Native· GraphQLA typed, client-driven API for application clients, without over-fetching. Composing data for a request/response API Native· OrbitalA query describing the response, planned across whatever holds the data. Native· GraphQLThe problem it was designed for, with a mature ecosystem behind it. ### Query and consumer model Orbital GraphQL Who defines the response shape Native· OrbitalThe consumer, in its own query, using its own field names and structure. Supported· GraphQLThe client, by selecting fields from the schema the graph publishes. Consumer-specific semantic modelTwo consumers holding genuinely different models of the same data. Native· OrbitalEach consumer declares its own model. None of them is canonical. Requires extension· GraphQLThe composed schema is the shared model; a different one is transformed outside the graph. Output formats other than JSONCSV, Avro, Protobuf, XML. Native· OrbitalA query’s output format is declared with its shape. Requires extension· GraphQLGraphQL responses are JSON; other formats are produced by a layer around the API. ### Source protocols Orbital GraphQL REST and OpenAPI Native· OrbitalThe specification is read directly; semantic types are annotations on it. Supported· GraphQLReached through resolvers, or declaratively through connector tooling. Databases Native· OrbitalSchemas are read and queried as a source like any other. Requires extension· GraphQLReached through resolvers, an ORM or a database-backed subgraph somebody owns. Protobuf, Avro and gRPC Native· OrbitalSchemas are first-class inputs to the model. Requires extension· GraphQLBridged into the graph by generated or hand-written resolvers. An existing GraphQL API Supported· OrbitalConsumed as one more source, which is what makes coexistence straightforward. Native· GraphQLA subgraph, composed into the supergraph. ### Workloads Orbital GraphQL Request and response Native· OrbitalA query, published as an endpoint. Native· GraphQLQueries and mutations, defined by the specification as stateless. Live push to a connected client Native· OrbitalA streaming query published over a websocket. Native· GraphQLSubscriptions, which the specification defines as stateful. Durable event streaming and CDCReplayable, at-least-once, consumer groups. Native· OrbitalA streaming query reads a topic, enriches each event and republishes it. Not the intended use· GraphQLSupplied by a streaming platform. Subscriptions are a live channel, not a durable pipeline. Batch and ETL Native· OrbitalA query reading from object storage, a database or an upload, writing wherever it belongs. Not the intended use· GraphQLOutside what the protocol set out to solve; handled by separate pipeline tooling. ## **Keep the graph.** Move the integration behind it. Bring one resolver that fans out across half a dozen services. We will model what it reaches and show you what is left of it. [Start for free](/docs)[Talk to us](/contact) ![](/assets/banner-cta-graph-axsXt434.webp)