Skip to main content

Orbital answers one query by fetching from several of your APIs and databases at once, working out the route itself.

It is for engineering teams whose data is spread across many services, such as a microservices architecture, not for end users of an app.

It removes the glue code engineers normally write by hand. That means calling one service, looping over the results, calling a second service for each one, then stitching the answers together.

Two systems can hold the same fact and not know it

One service might call a customer's identifier Customer.id, while another calls the same identifier Purchase.custId. Neither system records that these two fields mean the same thing. A human has to know it and write it into code by hand.

An accounts service stores a customer's ID as Customer.id, and a sales service stores it as Purchase.custId. An engineer writes code that maps one field name to the other, and that mapping breaks the day either field gets renamed.

The technical details

Orbital's own documentation calls this a lack of semantic metadata, meaning information that describes how data relates between systems, independent of field names. It distinguishes four roles a schema plays. Labels are field names like firstName, and structure is how a message is laid out, flat or nested.

Semantics is what the data actually means, and encoding is how it is written to the wire. Most schema languages describe labels and structure well but say almost nothing about semantics, which is the part a consumer cares about.

Orbital's docs give a table contrasting a field's name, its system type such as String, and its semantic type such as CustomerId. They note that when a producer renames a field, every hand-written mapping to that field breaks.

You tag the meaning once, in the specs you already have

Instead of rewriting your API or database schemas, you add a small tag to the fields that share a real-world meaning. The tag uses a language called Taxi. Once a field in each system carries the same Taxi type, Orbital treats them as the same thing, even with different names.

A team declares one shared type, type CustomerId inherits String. It then tags the id field in the accounts service and the custId field in the sales service both as CustomerId. Orbital can now recognise them as the same identifier without anyone renaming either field.

The technical details

The tag embeds directly into the API spec you already maintain. In an OpenAPI/Swagger spec, a field gains an x-taxi-type extension naming its semantic type. In Protobuf, a field gains a dataType annotation instead.

Neither requires migrating the underlying schema to a new format. Field names stay entirely up to each team.

Orbital's FAQ asks "Does this mean all my systems have to have the same ID schemes and request/response models?" The answer is no. Taxi is designed to let teams evolve independently, using shared semantic types to compose models rather than forcing one shared model on everyone.

Teams that cannot edit their specs directly still have options. They can work from a clone of the spec, or describe the service directly in Taxi.

You ask for the data you want, and Orbital works out the route

A query written for Orbital, in a language called TaxiQL, names the shape of the answer you want. Orbital works out which service to call and how to join the results, using the Taxi tags. The query never names a source, so the source can change underneath it without breaking anything.

A query such as find { Movie[] } as { title: MovieTitle, review: ReviewScore, awards: AwardTitle[] } can pull each field from a different source. The title might come from a database, the review from a REST API, and the awards from a gRPC service. Each source is named only in a code comment, not in the query itself.

The technical details

A TaxiQL query has the shape find { Type[] } as { field: SemanticType, ... }. Each requested field is a semantic type, and Orbital searches the graph of connected services for an operation that can produce it.

This can mean returning a value already present on the source object, or calling one or more further operations to look it up.

Because sources are never named, a database can be replaced with an API, or moved elsewhere, without touching any query that consumes it. Orbital's documentation states this as the payoff directly. Consumers remain unaffected as producers evolve.

Going deeper

How does Orbital work out which services to call?

Orbital treats every Taxi type as a node in a graph. A query becomes a request to find a path through that graph, from the data you already have to the data you asked for. It calls whichever services sit along that path, in whatever order the path requires.

There's no FROM, and there's no JOIN

Orbital's documentation names this in two subsections, "There's no FROM" and "There's no JOIN." A TaxiQL query never names the producer to fetch from. That decision is left entirely to the query layer, so consumers stay protected when producers change.

Likewise, a query never specifies how to navigate the infrastructure to link two pieces of data together. As Orbital's docs put it, understanding how data has been structured is an implementation detail a consumer should not need to know.

Orbital's introduction page states the mechanism in one sentence. It "leverages schemas to automatically work out which services to call, and sequences them together to pass data from service to service, in order to discover the data clients need." The GitHub README adds that under the hood, Orbital is a TaxiQL query server.

A concrete run, verified end to end

A hands-on Ritza walkthrough shows this in practice. An Order model and a Customer model, in two separate REST APIs, both share a tagged CustomerId type. A query asks for each order's ID, amount, and customer name, even though customerName is not a field on Order at all.

Orbital first calls the orders API to fetch the list of orders. It notices each order carries a CustomerId, and recognises that a second service accepts a CustomerId and returns a CustomerName. It then calls that service once per unique customer ID, reusing a cached result for any ID already looked up in the same query.

The combined result comes back as one JSON response, with no join code written by hand.

Where the documentation stops

Orbital does not publish a page on how its query planner chooses between two possible paths when more than one route exists. There is no documented account of cost-based optimisation. What is documented, consistently, is the graph-walking idea itself, not the fine detail of how ties between competing paths are broken.

How is this different from GraphQL?

Both promise one query returning shaped data from several sources, so Orbital's own documentation addresses the comparison directly rather than leaving it implied.

GraphQL works well once every service in a stack speaks GraphQL. For anything else, a team builds and maintains a separate shim layer, adapting a REST API, a database, or a message queue into GraphQL. Resolvers behind it do the actual fetching.

That shim layer is usually owned by a dedicated middleware or platform team. A service team that wants to change its own API has to coordinate with that separate team first.

Orbital instead embeds Taxi metadata directly into the API specs each team already owns, such as OpenAPI, Protobuf, Avro, or JSON Schema. There is no separate integration layer to build, and no dedicated team standing between a service change and its consumers. Orbital's README frames the tradeoff as decentralisation, with teams shipping changes independently and no middleman layer to keep in sync.

What can Orbital connect to, and how do you run it?

Orbital's connector list covers most of what a modern backend is built from. Unusually, which connectors you get does not depend on the tier you pay for.

Supported source types

Every tier, including the free one, supports REST and HTTP APIs, gRPC, relational databases, MongoDB, Kafka, RabbitMQ, AWS Lambda, AWS SQS and SNS, and GraphQL. Enterprise customers can add bespoke protocol support such as HL7 and FIX by working directly with Orbital's team.

Database support is documented in its own dedicated guide covering connection setup and column-level tagging. One company tutorial wires a REST API, a Postgres database, and a Kafka topic of Protobuf messages into the same instance, joined by a single query.

Running it

Orbital ships as a Docker image. It starts with a docker-compose.yml file generated for your operating system at start.orbitalhq.com, then brought up with a single docker compose up command. Configuration is passed through an OPTIONS environment variable or as individual environment variables in the Compose file.

Enterprise plans add air-gapped deployment, meaning Orbital runs without any license phone-home to Orbital's own servers. They also add a managed option where Orbital's team runs the deployment inside a customer's own cloud account.

What does Orbital cost?

Orbital prices on four tiers, scaled mainly by monthly call volume, user count, and how many endpoints you connect. The pricing page defines an endpoint as a database table, an API, a Kafka topic, a Lambda function, or a pipeline source or sink.

  • Free costs nothing, for 250,000 calls a month, 1 user, 5 endpoints, 1 environment, and community support.
  • Starter is 1,500 US dollars a month, for 2 million calls, 5 users, 20 endpoints, Prometheus metrics, and business-hours support, with overage priced at 1,000 US dollars per extra million calls.
  • Business is 70,000 US dollars a year, for 25 million calls, 15 users, 100 endpoints, 3 environments, SSO and SAML/OIDC login, and priority support, with overage priced at 405 US dollars per extra million calls.
  • Enterprise is priced on request, for 150 million or more calls, SSO with SCIM provisioning, air-gapped deployment, and 24 by 7 support with a named account manager.

Starter works out to 18,000 US dollars a year, so Business costs almost four times as much. That gap marks Starter as a small team's first production workload, and Business as a team already running an integration platform. These are the US dollar figures, and the same tiers are offered in British pounds.

Is Orbital open source, and who built it?

Orbital's source code is public and can be read and run by anyone, but it is not open source in the standard sense. This is worth stating precisely rather than repeating claims found elsewhere online.

Orbital is source-available, not open source

The repository at github.com/orbitalapi/orbital is public, with 360 GitHub stars at the time of research. Its LICENSE file states that the monorepo uses multiple licences, defaulting to the Business Source License 1.1. The Apache License 2.0 covers specific parts.

GitHub's own API confirms this indirectly, reporting the repository's licence as NOASSERTION, meaning it does not resolve to any recognised open-source licence. That is in contrast to the separate Taxi language repository, which resolves cleanly to Apache 2.0.

Some third-party sites describe Orbital's licence as GPLv3. That claim does not match the licence file itself and should not be repeated.

In practice, anyone can read and run Orbital's code. The Business Source License restricts some commercial uses in ways a standard open-source licence does not.

The name Vyne still shows up in the configuration

Orbital's current configuration options are still prefixed with the product's earlier name, Vyne. Flags such as --vyne.db.username and environment variables such as VYNE_DB_USERNAME appear throughout current documentation and in a working Docker Compose setup. This confirms the product was previously called Vyne, though no public page states when or why the rename happened.

Who wrote Taxi

GitHub's contributor data for the Taxi repository shows Marty Pitt as its principal author, with more commits than the next four contributors combined. That data supports crediting him as Taxi's main author. It does not establish a founding date, funding history, or team size for the company behind Orbital, which no first-party source confirms.

Sources

Last checked July 2026