Starburst and Trino in Azerbaijan: Federated Analytics Without Pipelines

Starburst is the enterprise distribution of Trino, the open-source distributed SQL engine. It queries data where it already lives — core banking systems, the data warehouse, object storage, operational databases — and joins across all of them in a single SQL statement, without copying anything into a central platform first. Yukon Labs implements it on-premise for organisations in Azerbaijan that cannot move their data into a foreign cloud.

That last constraint is why this article exists as a regional one. The international case for Starburst is about pipeline reduction and cost. Here, it starts one step earlier: for a supervised bank or a state institution, the centralise-everything-in-a-cloud-warehouse architecture is not available, and federation is not an optimisation but the practical route to enterprise analytics.

The problem it addresses

The shape is consistent across large Azerbaijani organisations.

Data lives in a core banking system that must not be queried heavily during business hours, a warehouse containing a curated subset that is two days old, several departmental databases, an archive on object storage, and an increasing amount in operational systems nobody planned for.

Every question that spans two of these becomes a pipeline. A pipeline is a request to the data engineering team, which has a queue. The queue is measured in weeks. Once built, the pipeline is a permanent maintenance obligation — it breaks when a source schema changes, and it never gets decommissioned because nobody is sure who depends on it.

The compounding effect is that the cost of answering a new question rises over time, which is precisely backwards. Organisations end up with hundreds of pipelines, a data engineering team fully occupied maintaining them, and analysts who have learned not to ask.

How federation changes it

Trino separates the question from the storage. It is a query engine with no storage of its own: it connects to sources through connectors — more than 30 production-grade connectors in open-source Trino, over 50 in Starburst — plans a distributed query across them, pushes down as much work as each source can handle, and joins the results in memory across a worker cluster.

Concretely, an analyst writes a single SELECT that joins oracle_core.banking.transactions to iceberg_lake.risk.customer_profile on customer_id, filters by transaction date, and groups by customer segment — counting distinct active customers and summing volume.

Read the table references again: the first is a schema inside the Oracle core banking system, the second an Apache Iceberg table on object storage. One statement, two entirely different systems, joined without a pipeline, without a copy and without a scheduled job to maintain.

The question that follows is always the same, and it is the right one: is that not slower than a warehouse?

For a well-tuned single-source query against a properly indexed warehouse, yes. For everything else, the comparison is misleading, because the alternative is not a fast query — it is a three-week wait for a pipeline. Trino's pushdown means filters, projections and aggregations execute in the source system where possible, so it is generally far closer to native performance than people expect. Starburst adds caching and materialised views for the queries that need to be fast repeatedly, and parallel JDBC connections per source — extracting from different partitions simultaneously — which addresses the single biggest bottleneck when federating traditional relational databases.

The trade is: near-warehouse performance on most queries, immediately, against warehouse performance on some queries, in a quarter.

What Starburst adds to Trino

Trino is open source and production-capable on its own. Several organisations run it directly, and that is a legitimate choice.

Starburst is the commercial distribution, and what it adds matters most to regulated institutions:

• Fine-grained access control — row-level and column-level policies applied consistently across every federated source, including sources whose own security model cannot express them. This is the single most valuable addition for a bank.
• A larger, supported connector set, including enterprise sources that the open-source connectors cover thinly.
• Parallel source extraction, caching and materialised views for repeated query patterns and JDBC-bound sources.
• Query performance tuning — a cost-based optimiser with improvements over the open-source baseline.
• Cluster management and autoscaling, which meaningfully reduces the operational burden.
• Commercial support, which is usually the deciding factor in a bank's procurement process regardless of the technical merits.

The honest summary: run open-source Trino if you have strong platform engineering and simple access-control requirements. Run Starburst if you need enterprise access control, broad connector support, or a supported product for compliance reasons — which describes most supervised institutions here.

Deployment in this market

On-premise is normal, not exceptional. Starburst runs on Kubernetes in your own data centre. The coordinator and workers are containers; the object storage layer can be MinIO or Ceph rather than a public cloud service. Nothing in the architecture requires internet connectivity at runtime.

It does not move your data. This is worth stating explicitly in security reviews, because it is the concern that comes up first. Trino reads from sources at query time and returns results. There is no persistent copy of source data inside the engine. From a data residency standpoint, federation is a considerably easier position to defend than centralisation, because nothing is ever relocated — which matters directly under the cross-border transfer rules discussed in data residency and personal data law in Azerbaijan.

It reduces load on the core system. A common objection is that federated queries will hit the core banking system. In practice, pushdown plus caching plus routing analytical queries to replicas gives you more control over core system load than the status quo, where every ad-hoc extract is a bespoke script somebody wrote.

It fits the supervisory posture. CBAR's Regulation on Information Security Management in Banks, in force since April 2022 and built on the ISO/IEC 27000 series, expects access control tied to classification. A federation layer that applies one consistent row- and column-level policy across every source is easier to evidence than the same rules re-implemented differently in six systems.

Trilingual metadata is a catalog problem, not an engine problem. Trino will happily join a Russian-named table to an Azerbaijani-named one. Knowing that they describe the same concept is the business catalog's job — see data governance in Azerbaijan.

What a first deployment looks like

Typical scope for a first engagement, six to ten weeks:

Weeks 1–2. Source inventory and connector validation. Which systems, what versions, what the access path is, what the security review requires. This phase surfaces the surprises, and there are always some — an unsupported database version, a network segment with no route, a system whose owner did not know it was in scope.

Weeks 3–4. Cluster deployment on Kubernetes, connector configuration, integration with the existing directory for authentication.

Weeks 5–6. Access control policy. Row and column-level rules mapped to existing roles. In a bank this is the phase that takes longest and matters most, because it is what allows analysts to be given direct access at all.

Weeks 7–8. Query enablement — connecting BI tools, migrating a set of existing reports to run federated, and measuring the difference.

Weeks 9–10. Performance tuning, caching strategy for the repeated queries, and handover.

The measurable outcome to define at the start is usually the same: a set of reports that currently require pipelines, running without them, with the engineering time released as the number.

Where it is the wrong choice

A single-source, high-concurrency serving workload. If a thousand concurrent users query one database with sub-second requirements, that is a well-indexed database's job, not a federation engine's.

Heavy batch transformation. Trino is an interactive query engine. Large-scale ETL is Spark's domain, and the two coexist in the same architecture rather than competing.

Organisations with no platform capability at all. Starburst reduces operational burden relative to raw Trino, but a distributed cluster still needs an owner.

When the real problem is that nobody trusts the data. Federation makes bad data reachable faster. If definitions are contested and lineage is unknown, governance comes first.

Key points

• Trino queries data where it lives and joins across systems in one SQL statement. Starburst is its enterprise distribution, with 50+ supported connectors.
• For supervised institutions here, federation is not an optimisation — it is the architecture that works when centralisation in a foreign cloud is unavailable.
• Nothing is copied. From a data residency standpoint this is easier to defend than centralisation.
• Starburst's decisive addition for banks is consistent row- and column-level access control across every federated source.
• Parallel JDBC extraction is what makes federating older relational sources perform acceptably.
• Wrong choice for single-source high-concurrency serving, heavy batch ETL, or as a substitute for governance.

Yukon Labs implements Starburst on-premise in Azerbaijan, and works alongside OvalEdge where the same estate also needs a governed business catalog. For the architectural background, start with data lakehouse architecture.