What is AI orchestration, and why can't we just call an LLM API directly?

AI orchestration is the layer between models and your organisation: routing, tool access, state, permissions and audit. You can call an API directly, and every project starts there. It stops working when the requirements arrive — look things up in our systems, only show what the user may see, explain an output from three months ago, nothing leaves the perimeter.

What is a data lakehouse, in plain terms?

A data lakehouse stores your data as open files on cheap storage while behaving like a warehouse when you query it. The warehouse was reliable but locked your data in one vendor's system. The lake was cheap but had no guarantees, and most became swamps. The lakehouse adds a metadata layer over the files — an open table format — that restores transactions, schema control and time travel.

What is Starburst, and how does it relate to Trino?

Trino is an open-source distributed SQL engine with no storage of its own; Starburst is its enterprise distribution, from the company founded by Trino's creators. Starburst adds what regulated institutions need: row- and column-level access control applied across every source, 50+ supported connectors, parallel extraction from JDBC sources, caching and commercial support. Running open-source Trino is legitimate if your access-control needs are simple.

Is Yukon Labs an official Starburst partner in Azerbaijan?

Yukon Labs implements and operates Starburst deployments in Azerbaijan as a delivery partner: cluster sizing, connector configuration, access policy design, directory integration and handover — or ongoing operation. What matters more than a badge in an evaluation is whether anyone in-region has deployed the product against a core banking system and a supervisory access-control requirement. A tool nobody local has deployed is a tool you will operate alone.

Do we have to move our data in order to use Starburst?

No — Starburst queries data where it already lives, so nothing has to be moved. That is the point of the architecture: it reads from each source reading from each source at query time. There is no persistent copy inside the engine. That also makes it easier to defend on data residency than centralisation: nothing is relocated, so the architecture itself raises no cross-border transfer question.

How does Starburst compare to Databricks and Snowflake?

Starburst, Databricks and Snowflake optimise for different things. If your data is already consolidated in one platform, that platform's engine is hard to beat on its own data. If it sits across many systems you cannot consolidate, Starburst is the strongest of the three and it is not close. For supervised institutions there is a prior filter: Databricks and Snowflake have no realistic air-gapped deployment.

What is Apache Iceberg, and do we need it?

Iceberg is an open table format — a metadata layer over Parquet files that gives you atomic commits, schema evolution, time travel and row-level deletes. You need it to build a lakehouse; you do not need it to start using Starburst, which also reads Delta, Hudi, Parquet and ORC. The format debate is settled in Iceberg's favour. The live question in 2026 is which * catalog * you commit to.

Can Starburst be deployed on-premise?

Yes — Starburst Enterprise can be deployed on-premise, running on Kubernetes in your own data centre: coordinator and workers are containers, and object storage can be MinIO or Ceph rather than a cloud service. Nothing requires internet connectivity at runtime. This is the normal deployment for Azerbaijani banks and government institutions.

How many data sources can Starburst federate at once?

There is no practical limit, and a single query can join across as many as it needs. Open-source Trino ships 30+ connectors; Starburst extends that past 50. The real constraint is the slowest source in a given query — which is why Starburst's parallel connections to a JDBC source matter more in a legacy estate than the connector count does.

Are federated queries slower than querying a warehouse?

Federated queries are slower than a well-tuned single-source warehouse query — but that is usually the wrong comparison. The alternative to a federated query is not a fast query; it is a three-week wait for a pipeline. Trino pushes filters and aggregations down into each source, so it lands far closer to native performance than people expect. Measure total time to answer, not query latency.

Does Starburst replace our BI tool?

No — Starburst does not replace your BI tool. It is a query engine, and your BI tool connects to it as it would to a database. What changes is reach: the same dashboards can query across the warehouse, the core system and object storage without a pipeline being built first. Most first deployments migrate a set of existing reports precisely so the difference is measurable.

What does a lakehouse migration typically cost and how long does it take?

A full lakehouse migration is a multi-year programme that frequently does not survive a change in priorities — which is why we recommend not doing one. Federate first: a query engine over the estate as it is delivers value in the first quarter and shows what people actually query. Then migrate individual datasets only where there is a reason. A first federated deployment is six to ten weeks.

How does access control work across federated sources?

Starburst applies one policy layer across every connected source, including sources whose own security model cannot express the rules you need. Row- and column-level policies map to your existing directory roles, so a user sees exactly what they are entitled to regardless of which system the data came from. One consistent policy is far easier to evidence to a supervisor than the same rules re-implemented in six systems.

What Is Data Virtualization?

Data virtualization queries data where it lives instead of copying it. How pushdown works, where federation beats a pipeline, where it does not, and how to size a first deployment.

Data virtualization is querying data where it already lives, across multiple systems, in one SQL statement, without first copying it into a central store. A federated engine takes the query, works out which parts each source system can execute, pushes those parts down, and joins the results.

The alternative — and the default for thirty years — is to copy everything into a warehouse first. That works, and it carries a specific set of costs: pipelines to build and maintain, storage paid twice, data that is as fresh as the last load, and a governance problem that grows with every copy, because each copy is a new place where personal data lives and a new thing to classify.

Virtualization does not replace that model. It complements it, and the useful skill is knowing which questions belong to which approach.

How it works

Four steps, and the third is where the engineering lives.

Catalog. The engine holds metadata about each connected source: schemas, tables, columns, and what the source can do. Fifty-plus connectors are standard for a mature engine — Trino ships more than 30 production-grade connectors covering relational databases, object storage, NoSQL and message systems.

Parse and plan. A single SQL statement referencing tables in three systems is decomposed into a distributed plan.

Pushdown. The engine sends each source the largest fragment that source can execute natively — filters, projections, aggregations, sometimes joins. This is the entire performance story. A query that pushes a filter down to Oracle transfers a thousand rows; the same query without pushdown transfers ten million and filters them in the engine. Pushdown quality varies enormously by connector and is the thing to test.

Execute and combine. Remaining joins and aggregations happen in the engine's own distributed workers, and the result returns as if it came from one database.

The source systems do not change. No agents, no schema modifications, no replication. That property is why virtualization is often the fastest path to a first cross-system answer in an estate where nobody is permitted to modify the core banking system.

Where it genuinely wins

Five situations, all common in this market.

Cross-system questions nobody has built a pipeline for. The question that spans core banking, the CRM and the loan origination system, asked once by risk, is not worth a pipeline. It is worth a query.

Data that cannot be moved. Regulatory or contractual constraints prevent copying a dataset into a central store. Federation reads it in place, which is sometimes the only lawful option.

Exploration before commitment. Before building a pipeline, find out whether the join is even useful. A large share of proposed pipelines do not survive this step, which is a saving rather than a failure.

Freshness requirements a batch load cannot meet. A federated query sees the source as it is now, not as it was at 02:00.

Reducing copies for governance reasons. Every copy is another asset to classify, secure and account for. Fewer copies is a materially simpler compliance position under Azerbaijan's personal data regime, and it is an argument that lands with a supervisor more reliably than a performance argument does.

Where it loses, and this matters more

Being specific here is what separates a successful deployment from a disappointed one.

Large joins across systems. Joining a hundred-million-row table in Oracle to a fifty-million-row table in Postgres means moving data across the network no matter how good the planner is. This is physics, not a tuning problem. Materialise it.

Load on operational systems. A federated query executes on your production core banking database. Analysts do not naturally write considerate SQL, and the first serious incident in most federation deployments is an analytical query degrading a transactional system. Resource limits and concurrency caps on operational connectors are not optional — and the JDBC connection bottleneck means a single source connection can also become the constraint on your own query performance.

Repeated heavy queries. A dashboard that runs the same expensive federated query every five minutes should be reading a materialised table. Federation is for questions asked occasionally, or for questions whose answer must be current.

Weak pushdown connectors. Where the connector cannot push down aggregation, the engine pulls raw rows and does the work itself. Performance collapses in a way that looks like an engine problem and is a connector problem.

Legacy sources with no query interface. Mainframe extracts and fixed-width files do not federate. They land, and then they participate.

The design rule that follows: federate for reach, materialise for repetition. Both belong in the same architecture.

Virtualization and the lakehouse

The two are frequently presented as competing and are complementary.

A lakehouse holds the data you have decided to centralise, in an open table format, with warehouse-grade transactional behaviour. A federated engine queries that lakehouse and everything you have not centralised — the core banking system, the regional legacy application, the SaaS platform — in one statement.

That combination is what makes an incremental migration possible. Instead of a two-year programme to move everything before anyone gets an answer, you stand up the engine, federate across what exists, and move datasets into the lakehouse when there is a reason to. The reason is usually query volume or join size, and it is a decision you can defer until the evidence exists.

Governance is the hard part

The capability that is easy to underestimate: federation makes it possible to join data that policy never intended to be joined.

Two datasets, each individually permitted for a user, can produce a re-identifying join. In a copy-based architecture that combination required a pipeline and therefore a review. In a federated architecture it requires a SQL statement.

Three controls address it. Identity propagation to the source, so that the query executes with the requesting user's entitlements rather than a shared service account — the same control that matters in every orchestration design. Column-level policy in the engine, so that masking and row filtering are applied centrally rather than per source. And query audit, because in a federated architecture the engine's query log is the only place the full picture of who joined what exists.

None of these are automatic. A federation deployment without them is a well-engineered way to bypass your access controls.

Sizing a first deployment

Six weeks, in this order.

Weeks one and two: connect three sources — one modern, one legacy, one that matters — and confirm pushdown behaviour on each with a real query. Measure rows transferred, not just elapsed time; rows transferred is what tells you whether pushdown is working.

Weeks three and four: implement identity propagation and column-level policy before any analyst gets access. Retrofitting is the same painful exercise here as it is in AI retrieval.

Weeks five and six: open it to a small analyst group with concurrency limits on the operational connectors, and watch what they ask. The queries they write will tell you which datasets deserve materialisation, which is a much better basis for a pipeline backlog than a requirements workshop.

Then decide, per dataset, whether it stays federated or moves to the lakehouse. That decision now has evidence behind it.

Key points

Virtualization queries data in place across systems; pushdown quality is the entire performance story and varies enormously by connector.
It wins on cross-system questions, immovable data, exploration before pipeline commitment, freshness, and reducing copies for governance reasons.
It loses on large cross-system joins, repeated heavy queries and weak-pushdown connectors. Federate for reach, materialise for repetition.
Federated queries execute on production systems. Concurrency and resource limits on operational connectors prevent the standard first incident.
Governance is the hard part: federation enables joins policy never reviewed. Identity propagation, central column policy and query audit are required, not optional.
Virtualization and the lakehouse are complementary, and together they make incremental migration possible.

We deploy Starburst — the enterprise distribution of Trino — for federated analytics in Azerbaijani institutions. Related reading: Starburst and Trino in Azerbaijan and data lakehouse architecture.

What Is Data Virtualization? Query Federation Without Copying Data