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.

Trino vs Presto: Which to Use

Trino and Presto share an origin and diverged in 2018. What the fork actually changed, how the two projects differ now, and which one a new deployment should choose.

Trino and Presto are two projects descended from the same code. Presto was created at Facebook and open-sourced in 2013. In 2018 its original creators left, forked the project as PrestoSQL, and renamed it Trino in December 2020. Facebook's line continued as PrestoDB under the Linux Foundation's Presto Foundation.

Both are distributed SQL query engines that read data where it lives rather than requiring it to be loaded first. Both are open source. Both are used at very large scale in production. The confusion in the market is entirely reasonable, because for the first year after the fork they were nearly the same software.

They are not the same software now, and for a new deployment the choice is straightforward.

What the fork was about

Understanding the split explains the divergence that followed.

The founding engineers — the people who wrote most of the engine — left Facebook and took the project's development momentum with them. What they did not take was the name, which stayed with Facebook, and the trademark question is what produced two names for what was briefly one thing.

The consequence was structural rather than technical. Development activity, the connector ecosystem and most of the visible community moved with the founders. Facebook continued developing its line for its own very large internal workloads, with the priorities that implies.

Neither project abandoned the other's design. But six years of independent development on different priorities produces genuinely different software, and that is where things stand.

Where they differ now

Development pace and community. Trino has the larger contributor base, the faster release cadence and the majority of new connector work. This is the difference that compounds: it determines how quickly a new data source, a new table format version or a new authentication method becomes available to you.

Connector coverage. Trino ships more than 30 production-grade connectors covering relational databases, object storage, NoSQL stores and message systems, with the enterprise distribution extending well beyond that. PrestoDB's coverage is narrower and weighted toward the sources Meta operates.

ANSI SQL conformance. Trino has invested heavily in standards conformance and in clear, predictable semantics. Queries written against a standard SQL reference tend to work, which matters more than it sounds when your analysts come from an Oracle or SQL Server background.

Table format support. Both support Iceberg, Delta Lake and Hudi, and both have improved. Trino's support has generally tracked new specification versions faster, which matters if you are running a format still under active development — see Iceberg vs Delta Lake vs Hudi.

Commercial support. Trino has Starburst, a substantial company built around it with enterprise distribution, security features and support contracts. PrestoDB's commercial ecosystem is thinner. For a regulated institution that needs a support agreement with a named counterparty, this is often the deciding factor rather than a nice-to-have.

Which to choose

For a new deployment: Trino, on the strength of ecosystem, connector coverage, release pace and commercial support. This is not a close call in 2026, and the honest reason is community gravity rather than any single technical feature.

The cases for PrestoDB are narrow but real. If you are already running it at scale and it is meeting your requirements, there is no urgency to migrate — the cost of a migration is real and the benefit is incremental. If your workload closely resembles Meta's and you benefit from optimisations made for that shape, that is a legitimate reason. And if your organisation has existing expertise concentrated in PrestoDB, that expertise has value.

What is not a good reason to choose either: benchmark numbers published by a party with an interest. At realistic scale, the difference between two configurations of the same engine typically exceeds the difference between the engines.

Migrating between them

Usually easier than expected, because the SQL surface is largely shared.

Most queries move unchanged. What requires attention is configuration — catalog definitions, connector properties, security integration — and any dependence on functions or behaviours specific to one line. The practical approach is to stand the new engine up alongside the old one, point it at the same sources, and run a representative query set through both. Differences surface quickly, and there are usually fewer of them than the planning meeting assumed.

Client compatibility rarely blocks a migration: JDBC and ODBC drivers exist for both, and BI tools generally connect without changes beyond the connection string.

What Starburst adds

Worth separating, because "Trino vs Presto" and "open-source Trino vs Starburst" are different questions that get conflated.

Open-source Trino is the engine. Starburst is the enterprise distribution built around it: additional and hardened connectors, fine-grained access control including row and column-level policy, a managed catalog layer, query result caching and materialised views, plus support and a security patch pipeline.

For a supervised bank, the ones that usually decide it are access control and support. Fine-grained policy applied centrally in the engine — rather than reimplemented per source — is what makes federated access compatible with a governance model, and it is a substantial engineering effort to build yourself. A named support counterparty is frequently a procurement requirement rather than a preference.

For a smaller deployment with strong engineering and no formal support obligation, open-source Trino is entirely viable, and it is the honest recommendation in that case. The detail is in Starburst and Trino in Azerbaijan.

Practical notes for this market

Three things that matter more here than in the material written for cloud-native estates.

On-premise deployment is normal for both, which is not true of every engine in this category. Neither requires a cloud service to function, and both run on your own Kubernetes or on bare metal. Verify this early, because it eliminates several competitors before you compare features — see Starburst vs Dremio vs Databricks.

Legacy connector quality is the real test. Your estate contains Oracle, MS SQL and possibly 1C and mainframe extracts. Test pushdown against those specifically. Modern-source performance is not in question; legacy-source pushdown is where deployments actually succeed or disappoint.

Concurrency limits on operational sources are not optional. A federated query executes on your production core banking database, and the JDBC connection bottleneck means a single source connection constrains both that system and your own query performance. Set the limits before the analysts arrive, not after the first incident.

Key points

Same origin, forked in 2018 when the original creators left Facebook; PrestoSQL became Trino in December 2020, and Facebook's line continued as PrestoDB.
Development momentum, connector coverage, release pace and commercial ecosystem all moved with the founders to Trino.
For a new deployment, choose Trino. PrestoDB is defensible if you already run it at scale or your workload resembles Meta's.
Migration is usually straightforward — most SQL moves unchanged; configuration and line-specific functions need attention.
"Trino vs Presto" and "Trino vs Starburst" are different questions. Starburst adds fine-grained access control, hardened connectors and support.
Test pushdown against your legacy sources, and set concurrency limits on operational connectors before opening access.

We deploy Starburst on-premise for federated analytics in regulated Azerbaijani institutions. Related reading: what is data virtualization.

Trino vs Presto: What Actually Changed and Which One to Use