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.

Iceberg vs Delta Lake vs Hudi

Three open table formats, one decision that shapes your engine choices for years. Where they differ on writes, catalogs and lock-in — and why the gap narrowed in 2026.

A table format is the layer that turns a directory of Parquet files into something that behaves like a database table: atomic commits, schema evolution, time travel, and a consistent view for readers while writers are working. Apache Iceberg, Delta Lake and Apache Hudi are the three open formats that do this, and choosing between them is one of the few lakehouse decisions that is genuinely hard to reverse.

It is hard to reverse because the format determines which engines can read your data efficiently, which catalog you run, and how much of your platform is portable if you change vendors. Everything else in a lakehouse — the engine, the orchestrator, the BI tool — can be swapped in a quarter. The table format is a multi-year commitment.

The short answer for most organisations building now: Iceberg, unless you have a specific reason. The rest of this article is about what those reasons are, and about how much the differences actually still matter.

What all three provide

Worth establishing the common ground, because vendor material tends to describe shared capabilities as differentiators.

All three give you ACID transactions over object storage — a commit either lands completely or not at all, and readers never see a half-written state. All three support schema evolution, so adding, renaming or dropping a column does not require rewriting the dataset. All three support time travel, letting you query the table as it was at a point in time, which is the capability that most often justifies the format to an auditor. And all three handle row-level updates and deletes, which plain Parquet on object storage does not, and which is what makes regulatory obligations like erasure requests tractable at all.

If your requirement is any of the above, all three satisfy it. The differences are in write patterns, catalog architecture and ecosystem.

Where they actually differ

Apache Iceberg was designed around engine neutrality. Its metadata is a tree of manifest files that any engine can read without a shared runtime, which is why it became the format that Trino, Spark, Flink, Snowflake, Databricks and most cloud warehouses all support natively. It handles very large tables well, its hidden partitioning removes a whole class of user error, and its specification is developed in the open with multiple substantial contributors rather than one dominant vendor.

Delta Lake originated at Databricks and remains most deeply integrated there. Its transaction log design is simple and effective, its performance inside the Databricks runtime is excellent, and its ecosystem outside that runtime has improved considerably but still trails Iceberg. If your platform is Databricks, Delta is the path of least resistance and the arguments against it are largely theoretical.

Apache Hudi was built for a specific problem: high-frequency upserts and incremental processing, particularly change data capture from operational databases. Its copy-on-write and merge-on-read table types give real control over the trade-off between write cost and read cost, and for streaming ingestion workloads it remains genuinely strong. Its ecosystem is the narrowest of the three and its operational complexity the highest.

What changed in 2026

Two developments matter for anyone making this decision now, and both narrow the gap.

The formats converged technically. At Iceberg Summit 2026, the v4 specification work was presented alongside the observation that Delta 5.0 adopts the same adaptive metadata tree structure as Iceberg v4. When two formats independently arrive at the same metadata design, the technical case for picking one over the other on performance grounds gets substantially weaker.

The catalog layer opened up. Apache Polaris graduated to a top-level Apache project in February 2026, giving Iceberg an open, vendor-neutral catalog implementation. This matters more than it sounds, because the catalog — not the format — is where lock-in actually lives. A table format is a file layout; the catalog is the service that tells engines which files constitute the current table, and a proprietary catalog can make an open format effectively captive.

The practical consequence: evaluate the catalog with the same seriousness as the format. An open format behind a closed catalog delivers less portability than the marketing implies.

The decision, honestly

Choose Iceberg if you are building now without an existing commitment, you expect to use more than one query engine, or engine neutrality has strategic value. This covers most organisations, and in this market it covers nearly all of them, because federated access across a mixed estate is usually the requirement.

Choose Delta Lake if your platform is Databricks and is going to remain Databricks. The integration advantage is real, and choosing Iceberg to preserve an optionality you will never exercise is a cost without a benefit.

Choose Hudi if your dominant workload is high-frequency upsert ingestion — CDC from operational systems at scale — and you have engineers who will invest in operating it. Outside that profile it is a harder platform to run for less benefit.

Do not choose based on benchmarks. Published comparisons are almost always produced by a party with an interest, on workloads chosen to suit, and the differences at realistic scale are smaller than the differences between two configurations of the same format.

What this means for an Azerbaijani deployment

Three local factors change the weighting.

On-premise object storage. These formats are usually described against S3, and a supervised bank is running MinIO, Ceph or an on-premise NAS. All three formats work, but their maturity against non-S3 storage differs, and the correct test is your own storage layer rather than a vendor's cloud benchmark. Verify atomic rename or conditional-put semantics on your actual object store before committing; this is where on-premise deployments actually break.

Federation matters more than format performance. If the practical architecture is a query engine reading both the lakehouse and the core banking system in one statement — which it usually is — engine neutrality is worth more than any format's peak throughput. That points to Iceberg, and it is consistent with Trino being the engine handling the widest range of source systems.

Time travel is a compliance feature. The ability to show a supervisor the exact state of a table on the reporting date, without maintaining snapshot copies, is a real answer to a real question. Set retention deliberately: too short and you lose the capability, too long and storage grows without limit and you retain personal data past its lawful period.

Migration between formats

It is possible and it is not free, which is why the decision deserves the time.

Converting a dataset between formats is mechanically straightforward — rewrite the metadata, sometimes the files. What does not convert is the surrounding estate: pipelines with format-specific write logic, engine configurations, catalog integrations, and the operational knowledge in the team. Budget for the estate rather than the data.

The practical mitigation is to keep format-specific logic thin. Write through an abstraction where you reasonably can, avoid depending on any one format's exclusive features unless they earn their keep, and keep the catalog choice open.

Key points

The table format is one of the few genuinely sticky lakehouse decisions — it determines engine compatibility and where lock-in sits.
All three provide ACID, schema evolution, time travel and row-level updates. Vendor material presents this common ground as differentiation.
Iceberg is the default for engine neutrality; Delta if you are committed to Databricks; Hudi for high-frequency upsert ingestion specifically.
The formats converged in 2026 — Delta 5.0 adopts the same adaptive metadata tree as Iceberg v4 — which weakens performance-based arguments.
Lock-in lives in the catalog, not the format. Apache Polaris graduating in February 2026 matters as much as any format feature.
On-premise: verify the format against your actual object store, not a cloud benchmark. That is where these deployments break.

We build lakehouses on open formats with Starburst as the query layer, deployed on-premise. Related reading: data lakehouse architecture and Starburst vs Dremio vs Databricks.

Apache Iceberg vs Delta Lake vs Hudi: Choosing a Table Format