Is Orbital a Data Mesh?

We’re often asked if Orbital implements a data mesh. It’s a fair question - and the answer depends on how you define “data mesh.”

Depending on how you found this blog post, there’s a strong chance you know what a Data mesh is, but may be less familiar with Orbital.

Orbital is a data integration platform that works across your entire stack - APIs, databases, and streams.

However, Orbital is a wee bit different from yer average iPAAS - it’s built around semantic metadata instead of complex pipelines.

Teams define what they need using plain business terms; Orbital handles the wiring and policy enforcement automatically.

Think of Orbital as:

• dbt, for APIs and streams (and DBs too) - transforming data across operational systems, not just SQL warehouses
• MuleSoft without the laborious manual orchestration - automated API orchestration and integration
• GraphQL Federation across all data sources - without resolvers to maintain, or a single uber-graph that breaks

Unlike traditional integration tools that help you write integration code, Orbital eliminates the need for it entirely.

Teams work independently, defining data contracts in Git using standard workflows. Orbital discovers and connects these distributed sources automatically.

Given this automated, decentralized approach, we often get asked: “Is Orbital a data mesh?”

Let’s unpack that question with a little architectural honesty.

​

Shared Goals

Orbital and data mesh share the same aspirations:

• Treat data as a product
• Decentralize ownership to the teams closest to the data
• Enable self-service discovery and delivery
• Ensure governance, quality, and interoperability

However, we didn’t set out to build a data mesh platform - so even though we share a bunch of the same goals, Orbital’s ended up a slightly different take.

​

Where Orbital delivers against Data Mesh

​

Decentralized ownership through Git

In many mesh architectures, decentralization is achieved by handing infrastructure, pipelines, and release cycles to individual teams - often with lots of tooling variation.

In Orbital, decentralization happens through standard GitOps workflows:

• Each team owns their repo
• They define data products using TaxiQL and metadata annotations
• They decide when to publish by merging to their nominated “production” branch

No central bottleneck. No handoff to a data engineering team.

Example: A sales team defines a CustomerRevenue product in their Git repo. They specify that only finance can access raw salary fields. Once merged, Orbital enforces those access rules automatically - across SQL views, APIs, and Kafka streams.

​

Favor declarative, shared semantic definitions over custom code

Orbital replaces pipelines with metadata. Data products are defined declaratively and generated automatically.

This enables:

• Business ownership of what a product is
• Engineering alignment through GitOps, versioning, and reviews

Teams don’t wire up Flink jobs or Spark DAGs. They define what they need in plain terms. Orbital figures out how to deliver it.

Getting into the detail is beyond this post, so if this part piqued you’re interest, here’s a few videos that you can douse your eyeballs with:

• Avoiding breaking changes using semantic metadata
• YOW Conference 2024 - Building API layers that build themselves
• Adaptive Architectures

​

Governance: Designed decentralized, enforced globally

​

What does "federated governance" actually mean in data mesh?

In theory, “Federated Governance” means domain teams define their own governance rules - such as data access, quality checks, and naming conventions - while a platform team provides shared tools and support.

In practice, that often leads to fragmentation:

• Teams define policies inconsistently
• Rules are duplicated or conflict across domains
• Enforcement is brittle or absent

​

Orbital's federated governance: strong in some areas, gaps in others

Where Orbital excels:

Data authorization: Teams define access policies using semantic annotations in Git. These rules are enforced automatically and globally - across APIs, queries, and streams.

Example: A team declares that only HR can view Salary. That rule applies automatically anywhere salary appears - no matter who published the product.

GitOps workflows: Teams use standard Git practices (PRs, reviews, branching) to federate governance around schema changes, policy updates, and data product definitions.

Lineage tracking: Traditional data mesh implementations require teams to manually document lineage as part of their data product pipelines - a process that’s error-prone and quickly becomes stale.

Orbital captures lineage automatically at runtime as queries execute and data flows between services. This ensures lineage always reflects what actually happened, not what was designed on paper. Teams get accurate, up-to-date lineage without the maintenance overhead.

This is computational governance at its best: federated by design (each team’s data products contribute to the overall lineage graph), but captured and enforced automatically by the platform.

Where Orbital has gaps today:

• Data quality enforcement: No built-in framework for teams to define and enforce quality rules (planned for future releases)
• SLA monitoring: No federated approach to defining or enforcing performance guarantees across data products
• Schema governance: Limited tooling for teams to define domain-specific naming conventions or structural standards

The result? Orbital delivers strong federated governance for access control, development workflows and lineage - but still requires external tools or manual processes for other governance concerns.

​

Self-serve infrastructure

One of the core principles of data mesh is self-serve infrastructure as a platform - enabling teams to build and publish data products without relying on central data engineering.

Orbital strongly supports this:

Teams can:

• Define products in Git using simple metadata
• Deploy those products over API (or as pipelines) simply by committing to Git
• Use Orbital’s browser-based editor to browse, author and deploy data products
• Discover and explore available products in a self-updating catalog

Orbital automates:

• API, SQL, and stream integration
• Catalog population and lineage tracking
• Access policy enforcement

Data integration happens automatically, without requiring coordination between teams.

This is infrastructure as a platform - without having to learn Airflow or build DAGs.

​

Where Orbital differs from traditional mesh tooling

Orbital doesn’t expose low-level orchestration tooling directly. Teams don’t:

• Write Airflow DAGs
• Build Spark jobs
• Manually configure Kafka pipelines

Instead, they define what the product should look like, and Orbital handles how it’s delivered - automating integration and orchestration beneath the surface.

To be clear: this doesn’t actually contradict data mesh principles at all - it simply diverges from the tools people commonly reach for.

Zhamak has been vocal that data mesh isn’t about pipelines - it’s about intent, ownership, and interoperability.

While many teams have implemented mesh with Airflow or Spark, Orbital takes a different path. We deliver the same outcomes with less complexity, by raising the level of abstraction.

That’s a simplification - and a strength. It avoids the complexity and inconsistency of DIY mesh implementations while still giving teams ownership over semantics, policy, and product lifecycles.

​

Open Source and Technology Agnostic

Taxi, the data product language that powers Orbital, serves dual purposes: it’s both a query language for discovering data products and a metadata language for publishing semantic information about APIs and data sources.

Taxi works alongside - not in place of - your existing definitions:

• Extend OpenAPI, Protobuf, Avro, and even legacy SOAP contracts
• Add semantic meaning to your existing data without a full rewrite
• Focus on what data means, not just how it’s structured

This schema-agnostic approach enables true semantic interoperability - the loose coupling that’s essential for Data Mesh success.

The core engine is Apache 2 licensed: The Taxi language, query engine, and execution engine are all open source and available on GitHub.

Orbital itself is Fair Source and also available on GitHub. Teams can work in whatever stack they prefer while Orbital provides the unifying layer.

​

Analytics vs. operational data: where data mesh draws unnecessary lines

The early Data Mesh literature made the somewhat puzzling decision to limit its principles exclusively to analytical data.

This artificial boundary creates unnecessary silos between operational and analytical systems - exactly the kind of fragmentation that data mesh supposedly aims to solve.

Orbital takes no such stance. We’re used by both analytics and operations teams across the same organizations:

• Analytics teams use Orbital to power batch data jobs for ML pipelines and data science workflows
• Operations teams use Orbital to federate APIs and databases into real-time services powering some of the largest banks in the world

The underlying challenges - data discovery, semantic alignment, governance, and integration complexity - are identical whether you’re building a quarterly sales report or a real-time fraud detection system. Why artificially limit solutions to only half the problem?

While the Data Mesh community has chosen this hill to die on, we see it as a false dichotomy.

Good data architecture principles should work across the entire data spectrum.

​

TL;DR

Orbital isn’t a data mesh by the book. But it aligns closely with its four foundational principles:

• Domain-oriented ownership - Teams manage their own products via Git, with full lifecycle control
• Data as a product - Products have contracts, owners, and real consumers
• Self-serve infrastructure - No pipeline authoring needed - Orbital automates delivery
• Federated governance - Policies are defined decentrally, and enforced globally

And one bonus principle:

• Technology-agnostic - Taxi integrates with your existing schemas, rather than replacing them

You get the outcomes of data mesh - without the overhead of implementing one.

So is Orbital a data mesh?

Kinda.

Orbital delivers the goals of data mesh - but in a way that’s actually usable, scalable, and maintainable.