Federated Queries. Heterogeneous Sources. Zero Data Movement.

No. xLake is built on the principle of zero data movement. Queries execute against your sources in place — whether they live in a cloud warehouse, object storage, an operational database, or an on-prem system. Results are returned directly to the requesting application. No intermediate copies, no sync jobs, no replication pipelines.

Governance is enforced at the query layer, not the storage layer. Before a single byte is read, xLake evaluates access controls and catalog visibility natively — as part of query execution, not as a downstream audit step. This closes the gap that exists when governance tooling is separate from the query engine.

xLake runs on your Kubernetes clusters. It is compatible with EKS, AKS, GKE, and any on-prem Kubernetes environment running version 1.20 or later. You control resource limits, scaling rules, and cost ceilings. xLake does not require vendor-hosted compute or a cloud-provider control plane.

Minimal to none for most workloads. xLake's query engine is built on Trino, which uses standard SQL. Existing Trino SQL workloads are compatible at a 98% rate across cloud and on-prem environments. Teams do not need to rewrite queries when moving between environments or adding new sources.

Yes. That is a core use case. xLake maps cloud warehouses, object storage, operational databases, and on-prem systems into a unified metadata layer through standard connectors. A single SQL statement can span multiple heterogeneous catalogs — regardless of where those sources physically reside.

xLake provides execution-layer observability, not just lineage. Granular metrics and routing logs capture which catalogs were accessed, which connectors were invoked, and which nodes executed each stage of a query. When a cross-source join fails or slows, you can trace the issue to the specific catalog, connector, or node — rather than working backward from an opaque error.