Orbital, Hasura, and Apollo all do similar things. But when agents write most of your software, the choice between them is made for you. Here’s which one your agent prefers, and why.
Using Claude Code, we followed our audit method to assess their agent experience (AX) across four stages.
The four stages of an AX audit
The audit follows the funnel a developer goes through with their agent:
Awareness → Discoverability → Reputation → Integration
We started with what the model knew without tools, then tested online discovery and recommendations with web search and fetch, and finally attempted a working integration with the full toolset. Explore the interactive audit diagram and exact prompts in the original article.
- Awareness: Does the model already know about the product, without tools?
- Discoverability: Does it find the product when it searches online?
- Reputation: Does it recommend the product over alternatives, and get the facts right?
- Integration: Can it build and verify a small working integration?
Each stage gets a score from 1 to 4: GOOD (4) means little friction; OK (3) means minor gaps; POOR (2) means a partial result with significant gaps; FAIL (1) means the product is unknown or the task doesn't work.
How we tested
All testing used Claude Opus 5.5 (claude-opus-5-5) in Claude Code 2.1.287, on 13–14 October 2026. Every session started in a fresh folder with no audit context or user customizations. Each integration used its own fresh Claude Code profile and a folder containing the supplied test data. Those profiles loaded no MCP servers and only built-in skills and plugins, and we approved every command. Awareness questions ran with no tools, and discoverability and reputation questions with web search and web fetch only. We ran each prompt once, so treat these results as one developer's experience rather than a benchmark.We chose Hasura and Apollo GraphQL by asking six questions about Orbital's job and its alternatives, and taking the products the answers named most. Both appeared in all six answers. WunderGraph Cosmo did too, and we picked Apollo because Orbital's own comparison pages measure it against GraphQL tools like Apollo. The shared questions describe Orbital's problem (data spread across REST APIs, databases and Kafka), so they suit Orbital more than the other two.
What are Orbital, Hasura and Apollo GraphQL?
All three let an app or an agent ask one API for data that lives in several systems.
Orbital sits in front of your existing APIs, databases and message streams. You describe what the data in each system means once, then ask Orbital for the data you want, and it works out which systems to call and joins the results. Our Orbital quickstart covers how it works in more detail.
Hasura turns databases and APIs into one GraphQL API, and its company now also sells an AI agent product, PromptQL. Apollo GraphQL makes widely used GraphQL tools, including a router that combines many services into one API and Connectors that map REST APIs into it without code.
Results at a glance
🥇 Hasura (1st) — Known and found by agents; retrieved credentials and ran a script after browser login
🥈 Apollo GraphQL (2nd) — Known and found by agents; ran a script after we logged in and created a key
🥉 Orbital (3rd) — Won the named head-to-heads; never found unprompted, and its script stopped at authentication
| Stage | Orbital | Hasura | Apollo GraphQL |
|---|---|---|---|
| Awareness | OK (3) | GOOD (4) | GOOD (4) |
| Discoverability | FAIL (1) | OK (3) | OK (3) |
| Reputation | GOOD (4) | OK (3) | OK (3) |
| Integration | FAIL (1) | OK (3) | POOR (2) |
| Overall (average) | 2.25 | 3.25 | 3.0 |
The averages are not rounded. Hasura places first because its agent obtained credentials after browser login; Apollo needed us to create its key too.
Orbital vs Hasura vs Apollo GraphQL: which should you choose?
The agent's recommendation depended on your data: "use Orbital to combine mixed sources including Kafka without code, Hasura for an instant API over mainly SQL databases, and Apollo to federate GraphQL services owned by many teams."
Agents chose Orbital when the data includes Kafka topics and you want joins without writing code for each system, and it won every head-to-head on those grounds. Name Orbital explicitly, and be prepared to check script authentication yourself: our agent installed Orbital but couldn't get data back with the key we supplied.
Agents recommended Hasura when "your data is mostly relational and what you want is a fast, auto-generated GraphQL API over it". Against Apollo, the agent preferred Hasura in one order and neither in the other. Our agent used Hasura DDN, retrieved a token after our browser login, and ran a script that authenticated to Hasura Cloud and fetched local customer and order data. The local data queries used no token. When we asked about risks, the agent raised Hasura's shift towards its AI product, PromptQL.
Agents preferred Apollo when "Your consumers want GraphQL" or "Your sources are mostly REST", and said it "has a much larger community and is easier to hire for". It doesn't connect to databases or Kafka without extra services, which is why it lost both head-to-heads with Orbital. After we signed in and created a personal key, our agent used it to query GraphOS account information and also queried local customer and order data. The local router used no credentials.
Awareness: does the model know Orbital?
Awareness tests what a model knows from training data alone, with no web search.
Orbital: OK (3 / 4) — Knows it as a data gateway; doesn't know "governed context layer"; never named unprompted
Hasura: GOOD (4 / 4) — Accurate, and named for Orbital's job without a search
Apollo GraphQL: GOOD (4 / 4) — Accurate, and named for Orbital's job without a search
We first described Orbital's job without naming any product. Asked which tools let apps and AI agents query data across REST APIs, databases and Kafka without integration code, the model named Hasura, Apollo and WunderGraph Cosmo, among others. When we described one self-hosted layer with Orbital's main capabilities, it picked Grafbase, with Hasura DDN and Apollo as the alternatives. Orbital appeared in neither answer.
Then we named each product with its domain, in a fresh session with no tools: "What is Orbital (orbitalhq.com)?", and the same question for Hasura (hasura.io) and Apollo GraphQL (apollographql.com). The model described all three accurately:
| Company | Answer (excerpt) |
|---|---|
| Orbital | "Orbital (orbitalhq.com) is a data integration platform, sometimes described as a "data gateway" or "integration without glue code." It comes from the team that previously built Vyne, which Orbital is essentially the successor to." |
| Hasura | "Hasura is a company and an open-source product that automatically generates a GraphQL API (and, in newer versions, other API styles) on top of your existing databases and services." |
| Apollo GraphQL | "Apollo GraphQL (apollographql.com) is a company that builds a widely used platform and set of open-source tools for working with GraphQL, the query language for APIs that Facebook originally created." |
For Orbital, it described Taxi, the query language, joins across APIs, databases and Kafka, and the self-hosted Docker setup, but didn't mention AI agents or MCP. For Apollo, it mentioned the Apollo MCP Server.
Next we used each company's tagline from its own site, with no domain. The question for Orbital was: "What do you know about Orbital, the 'governed context layer'? What does it do, and who is it for? Say clearly if you don't know." Hasura's and Apollo's versions swapped in their own name and tagline. Orbital's homepage turns "your existing APIs, databases and streams into a governed context layer", and the model didn't connect that phrase to Orbital:
| Company | Tagline | Answer (excerpt) |
|---|---|---|
| Orbital | "governed context layer" | "I don't know what this is. I have no reliable information about a product called "Orbital" described as a "governed context layer," so I can't tell you what it does or who it's for." |
| Hasura | "universal data access layer" | "…It is metadata-driven, uses a pluggable connector spec (NDC) for arbitrary data sources, and is where the "universal data access layer" positioning mainly comes from." (about Hasura DDN) |
| Apollo GraphQL | "domain model for AI" | "I'm not certain Apollo uses that tagline, or how they currently frame it. It fits the direction I described, with the graph as the semantic layer between your APIs and AI." |
For Orbital, it listed Orbital Insight, a geospatial analytics company, as one of several unrelated things called Orbital. For Hasura and Apollo, it described the products accurately either way.
Asked how to join two REST APIs with Orbital on a laptop, the model gave the right shape of a setup: Docker, a Taxi project with a shared customer ID type, and a query. Its first command saved https://start.orbitalhq.com as a Docker Compose file, even though that address serves Orbital's launcher script. It also didn't mention the sign-in Orbital needs on first start.
What this means if you're choosing
Without web search, an agent suggests Hasura or Apollo for this job. If you want Orbital considered, name it. The model knows it as a data gateway, which is how Orbital's docs describe it, but not by the "governed context layer" description on its homepage.
Discoverability: can an agent find Orbital?
Discoverability tests whether an agent with web search finds a product while looking for a tool like it. We repeated the two awareness questions with web search, then ran two six-question funnels that narrowed a broad problem towards Orbital. The first four questions were the same for all three companies. Each funnel branched at question 5, where we asked for products using that company's tagline; we named the company at question 6.
Orbital: FAIL (1 / 4) — Only found when named, in both funnels; its tagline search found Cube
Hasura: OK (3 / 4) — Named at question 1 or 3; its tagline search found it both times
Apollo GraphQL: OK (3 / 4) — Named at question 1 or 3; its tagline search found it once
With web search, the two open questions named Hasura and Apollo again, but not Orbital. One query came close to Orbital's description: self-hosted GraphQL federation REST databases Kafka no resolvers field-level authorization 2026. The answer said no tool absorbs upstream API changes:
Funnel A targeted a platform engineer tired of glue code between microservices; funnel B followed a team building AI agents, the audience Orbital's homepage now speaks to. Here is funnel B on the Orbital branch, with the start of each answer:
At question 4 the agent searched for "context layer" OR "data gateway" for AI agents startup launch 2026 governed access internal systems, which uses both of Orbital's descriptions, without finding Orbital. At question 5, Orbital's tagline led to Cube, whose AI Context Layer page says "Cube gives your AI agents a governed context layer". Funnel A's tagline search went the same way, listing Cube, Starburst, Denodo and Atlan:
| Funnel | Orbital first appears | Hasura first appears | Apollo GraphQL first appears |
|---|---|---|---|
| A: platform engineer | Question 6 (named) | Question 1, in a list of federation tools | Question 1, in the same list |
| B: team building AI agents | Question 6 (named) | Question 3 | Question 3 |
Hasura's tagline, "universal data access layer", returned Hasura in both funnels. Searching Apollo's tagline, "domain model for AI", returned Apollo in funnel A and SAP's domain models in funnel B.
What this means if you're choosing
If you shortlist tools by asking an agent to search, expect GraphQL federation tools: The Guild's Hive stack, Grafbase, WunderGraph Cosmo, Apollo and Hasura. Orbital didn't come up in any of our searches for this problem, so add it to the list yourself.
Reputation: do agents recommend Orbital over Hasura and Apollo GraphQL?
Reputation tests what an agent with web search says about each product once it's in the conversation. Every question described the same use case: "joining data across our REST APIs, databases and Kafka, self-hosted, without integration code".
Orbital: GOOD (4 / 4) — Picked over both, in every head-to-head and in the three-way question
Hasura: OK (3 / 4) — Recommended when the data is mostly in databases; split with Apollo
Apollo GraphQL: OK (3 / 4) — Recommended for GraphQL teams with mostly REST APIs; lost to Orbital, split with Hasura
Asked for the single best tool, with no product named, the agent picked ClickHouse and didn't mention any of the three.
Once all three were named, the agent chose Orbital, answering from what it already knew without a search:
Apollo vs Hasura: how do they compare with Orbital?
Orbital beat both Hasura and Apollo, in both orders. For Hasura vs Apollo GraphQL, the result was a split. We asked each pair in both orders because agents can favour the product named first, and a pair counts as a win only if the same product wins both ways.
| Pair | Named first | Named second | Result |
|---|---|---|---|
| Orbital vs Hasura | Orbital | Orbital | Orbital wins |
| Orbital vs Apollo GraphQL | Orbital | Orbital | Orbital wins |
| Hasura vs Apollo GraphQL | Neither: "neither is a great fit for all three requirements together" | Hasura | Split |
In each Orbital head-to-head, the agent searched for Orbital and cited its Kafka support and joins that need no code per system. With Hasura named first against Apollo, it recommended Grafbase or WunderGraph Cosmo if Kafka matters.
The last question used each product's bare name, with no domain. The agent recognised Hasura and Apollo GraphQL and flagged Hasura's shift towards PromptQL and v2.45 LTS reaching end of support on 1 January 2027, plus Apollo's Elastic License and usage-based pricing. Asked about "Orbital" on its own, it returned information about a different industry:
What this means if you're choosing
Named side by side, Orbital won on Kafka support and joins without per-system code. Hasura and Apollo each won a narrower case: Hasura for data that sits mostly in databases, Apollo for mostly REST APIs. Our questions described a mix of REST APIs, databases and Kafka, which is Orbital's own use case. When you ask an agent about Orbital, give it the URL: on its own, "Orbital" brought up data centres in space.
Integration: can an agent build with Orbital?
Integration follows three steps: sign up or install, get a credential for a script, then write and run a script that returns real data. Each company had one continuous session. The agents had shell access, web search and fetch, but no browser tool. We handled browser steps when asked. The test folders included two small REST services for customers and orders.
Orbital: FAIL (1 / 4) — Installed, but the supplied key returned errors and no data
Hasura: OK (3 / 4) — Human browser login; agent retrieved the token and ran a script
Apollo GraphQL: POOR (2 / 4) — Human account access and key creation; agent ran a script
The first request was: "Sign me up for Orbital, or install it if that's how it works, and get it ready to use. Do what you can yourself and tell me where you need me." Hasura and Apollo GraphQL received the same prompts with their names substituted.
| Company | Sign up / install | API key / access token | Hello world |
|---|---|---|---|
| Orbital | Agent installed Docker stack; browser reused our existing account | Human created a key and saved it to .env
|
Stuck: authenticated calls returned HTTP 500; no data |
| Hasura | Agent installed DDN CLI; human completed browser authentication | Agent retrieved the CLI token and saved .env
|
Agent ran a script: authenticated cloud project listing, plus local customer/order queries |
| Apollo GraphQL | Agent installed Rover; human handled Studio account access | Human created a personal key and saved .env
|
Agent ran a script: authenticated cloud account query, plus local customer/order queries |
Orbital: installed, then stopped at authentication
Orbital's agent downloaded and read the official launcher, started the Docker stack, and checked that its health endpoint returned 200. Our existing Orbital account signed in automatically in the browser.
Asked to get a credential, the agent searched the docs, probed the API and inspected the local UI. It didn't obtain a key or write .env. We created an API key and saved it ourselves so the next step could test whether the agent could use it. Requests with that key returned HTTP 500, and the agent found this message in Orbital's logs: API Key authentication is not enabled.
We didn't test script authentication with other Orbital configurations.
Hasura: browser login, then the agent got the token
Hasura's agent chose DDN, installed its CLI and asked us to complete browser authentication. After that it used ddn auth print-access-token to save a token privately, without asking us to create or copy one.
The agent generated two OpenAPI connectors, fixed a Docker build failure and missing environment settings, then ran query_hasura.py. Its saved token authenticated a Hasura Cloud project-list request. Separately, the local engine returned Luca Ibrahim and nine orders, with a completed-order total of 2,669.39, matching our test data. That local engine didn't require a key. The script fetched the customer and orders with two queries in one request; it hadn't created a relationship between them.
Apollo: we created the key, then the script worked
Apollo's agent installed Rover through Homebrew and tested a local customer query. When asked for credentials, it started a browser login but stopped to ask which account, organization and key type to use.
We created a personal key in Studio and saved it to .env. The agent wrote query.py, fixed a missing client-version header, and ran it successfully. The key authenticated a GraphOS query returning our account and team information. A separate request to the local router returned Luca Ibrahim with the same nine orders. The local router answered without credentials.
Hasura's and Apollo's integration scores reflect who handled account access and credentials, plus whether a script ran successfully.
What this means if you're choosing
- Orbital installed successfully, but browser sign-in and a supplied key didn't get our agent to a working script.
- Hasura required browser authentication, then the agent obtained its token and completed the script. It also repaired generated connector files along the way.
- Apollo's agent completed the script after we created and saved the personal key. With either Hasura or Apollo, check local API authentication before using the demo with private data.
Top comments (0)