Starburst Support Options: Enterprise, Galaxy, Trino or Independent

Starburst support comes from Starburst for Starburst Enterprise and Starburst Galaxy customers, from the community for open-source Trino, and from independent providers for the clusters that fall between the two: releases past their support window, Trino without a vendor contract, and the operational work around the query engine. The supported window on Starburst Enterprise is twelve months, which is shorter than most data platform teams plan for.

How Starburst Enterprise releases are supported

Starburst Enterprise Platform (SEP) is built from Trino. Starburst's product versions page says an SEP release is created for each Trino open source release, using the open source code and adding Starburst's extensions and plugins. Those releases come in two kinds:

• Long-term support (LTS) releases ship at most once a quarter and are supported for use in production for 12 months. They receive backported critical security fixes and selected fixes for critical defects that affect production usage.
• Short-term support (STS) releases ship shortly after each Trino release and are supported only until the next STS release is available. They receive no patches; a fix arrives in the next release.

At the time of writing the supported LTS lines are 477-e (end of support 30 November 2026), 479-e (28 February 2027), 480-e (31 May 2027) and 482-e (31 August 2027). Anything older is outside vendor support, contract or not. A cluster that was upgraded once and left alone for a year has aged out.

Starburst Galaxy and open-source Trino

Starburst Galaxy is the managed service. Starburst runs the platform, so version currency is its problem rather than yours, and support comes with the service. Open-source Trino is the opposite case: Apache 2.0 licensed, free to run, and supported by the community through Slack and GitHub. There is no contract, no response time and nobody to page. Plenty of production analytics runs on it anyway.

Where independent Starburst and Trino support fits

• SEP clusters past the 12-month LTS window that cannot be upgraded on the vendor's cadence because of change control or connector dependencies.
• Open-source Trino in production with no vendor behind it.
• Problems that are about the workload, not the product: workers killed by out-of-memory errors under one wide join, federated queries that are slow because of the source system and not the engine, catalog and connector misconfiguration, spill and resource group settings that were never tuned.
• The data sources themselves. A federated query is only as fast as the slowest system it touches, and vendor support stops at the connector.

AceMQ provides 24/7 Starburst support for Starburst Enterprise and Trino, with a 15-minute emergency SLA and named senior engineers. Examples of the work: a Trino worker out-of-memory remediation and query latency support on a federated estate.

The Starburst and Trino incidents that actually page people

• Workers killed for memory. A query with a large join or a skewed distribution exceeds its per-node memory, or the operating system kills the worker. Memory settings, spill to disk, fault-tolerant execution and join ordering all matter, and the right mix depends on whether the cluster serves dashboards or batch ETL.
• Slow federated queries. Trino is fast. The PostgreSQL, Oracle or object storage behind it may not be. Predicate pushdown that does not happen, missing table statistics and small-file problems in a data lake are the usual findings.
• Hive metastore and catalog problems. A slow or overloaded metastore delays query planning for every user. Iceberg and Delta tables add their own maintenance: compaction, snapshot expiry and orphan file cleanup.
• Noisy neighbours. One analyst's query starves the scheduled reports. Resource groups and query limits exist to prevent this and are rarely configured until it has happened.
• Coordinator as a single point of failure. The coordinator plans every query. When it runs out of heap or restarts, every running query fails. Sizing, query limits and a tested restart procedure decide how long that outage lasts.

Staying inside a twelve-month LTS window

With a new LTS at most once a quarter and twelve months of support for each, a Starburst Enterprise cluster needs at least one planned upgrade a year, and jumping across several Trino versions at a time means a long list of release notes to read. The items that break in practice are connector configuration properties that were renamed or removed, the Java version the new release requires, changes to SQL behaviour that affect saved queries, and custom plugins or UDFs built against an old SPI. A staging cluster that replays a sample of production queries is the most useful test there is. Open-source Trino users face the same upgrade work with a release almost every week and no LTS line at all.

Choosing

On Galaxy, use the support you are already paying for. On SEP and current on an LTS line, vendor support covers product defects well. If you are on Trino, behind on SEP, or your incidents are about how the cluster is used, you need support that covers the version and the workload you actually run.