Orbital vs Hasura vs Apollo: AI Agent Review

Posted on Oct 22 • Originally published at techstackups.com

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 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.

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.

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.

🥇 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

The averages are not rounded. Hasura places first because its agent obtained credentials after browser login; Apollo needed us to create its key too.

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 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:

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:

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.

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 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:

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.

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 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:

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.

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:

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 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.

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'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'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.