Starburst Enterprise Versions — LTS vs STS, Numbering, and Upgrade Strategy

If you operate Starburst Enterprise Platform (SEP) in production, the single most consequential operational decision is which version you run, and for how long. SEP's version policy is deliberately built around two release tracks — LTS and STS — that map directly to the open-source Trino release cadence. Choosing between them, and knowing when (and how) to move, is the difference between a quiet platform and a quarterly fire drill.

This post summarizes the official SEP versions policy and turns it into something you can act on: numbering rules, the lifecycle of each release type, the currently supported versions, and the upgrade strategy we actually recommend to customers.

---

1. Why SEP versioning is different

Starburst Enterprise is a commercial distribution of Trino (the open-source MPP SQL engine, formerly PrestoSQL). Trino itself ships a new minor release roughly every two weeks — that's a fantastic pace for the upstream community, but unworkable for most enterprise platforms.

SEP solves this by overlaying two things on top of Trino's release stream:

1. A predictable cadence: only selected Trino releases become SEP releases, and only some of those become LTS.
2. A patch lifecycle on LTS: critical bug fixes and security fixes get backported into the LTS line for a year, so you don't have to chase Trino's biweekly trains to stay safe.

Everything in this post follows from those two ideas.

---

2. Version numbering — read the number, know the release

SEP version numbers are designed to be self-descriptive. Once you know the three pieces, you never have to look up what a version is — only what it contains.

Trino release         →   338
SEP (STS) release     →   338-e          ← Trino number + "-e"
SEP (LTS) release     →   338-e.0        ← STS format + patch number
                          338-e.1        ← LTS patch 1
                          338-e.2        ← LTS patch 2
                          ...

A few practical consequences:

• The integer prefix is always the upstream Trino version. 479-e and Trino 479 contain the same engine features.
• A patch suffix (.x) means LTS. No suffix means STS.
• Patch numbers move forward only inside one LTS line. 479-e.1 → 479-e.2 is a patch upgrade; 479-e.x → 480-e is a different release entirely.

---

3. LTS vs STS — what each one actually guarantees

These are not marketing labels. They define different contracts between Starburst and you as the operator.

LTS — Long-Term Support

• Supported for 12 months from the initial release.
• At most one LTS per quarter, so you get a small, predictable set of options per year.
• Receives patch releases (the .x suffix) throughout the 12-month window.
• Backports include:
  • Critical security fixes (typically CVEs).
  • Select fixes for critical defects that affect production and have no workaround.
• New features are never backported. If a feature lands in a newer release, you only get it by moving to that release.

LTS is the default recommendation for production. You stay on one line, take patches as they come, and plan a single, controlled upgrade per year.

STS — Short-Term Support

• Supported only until the next STS release becomes available.
• Released shortly after each Trino open-source release of the same version.
• No patches. Any fix lands in the next STS release, not as a patch on the current one.

STS is the right choice when you need a feature that hasn't reached LTS yet, or when you're explicitly running closer to upstream Trino. The trade-off is that you accept a continuous upgrade treadmill — there is no "stay here for a year" mode on STS.

Side-by-side

---

4. Currently supported LTS versions

Below are the LTS releases still inside their 12-month support window, plus the most recent ones for reference. STS-wise, only the latest STS is supported at any given time — at the time of writing that is 480-e (April 2026).

Two things are worth reading off this table:

• The cadence is quarterly — February, May, August, November.
• Because each LTS line lives for 12 months, you always have roughly four overlapping supported LTS lines to choose from. That overlap is the upgrade runway.

Always confirm the current list on the official versions page — the table above reflects the policy and recent history, but the supported set rolls forward each quarter.

---

5. Upgrade strategy — what we recommend in the field

The official guidance is short and clear:

"We recommend upgrading to an LTS release if possible, to ensure that the version you are upgrading to is supported with security patches and fixes for the full support window."

In practice, here is the playbook we use with customers:

5.1 Default path: LTS → next LTS, once a year

1. Pick a target LTS line with at least 9–12 months of remaining support.
2. Read the SEP breaking changes reference for every LTS line between your current version and the target. Breaking changes accumulate — you have to address them in sequence, even if you jump straight to the target.
3. Stage the upgrade in a non-prod environment, run your real workloads (not just smoke tests), and validate connectors, security integrations, and UDFs.
4. Cut over to the new LTS, then stay on its patch line (-e.0 → -e.1 → -e.2 …) for the rest of the year.

5.2 When you need a feature before it reaches LTS

If a new Trino capability you need is in an STS but not yet in any supported LTS:

• Move to the current STS to get the feature.
• Accept that you will upgrade with every STS release until an LTS version that contains the feature ships.
• As soon as that LTS lands and you've validated it, switch back to the LTS track.

This is the path the docs explicitly describe: "you can change to use an STS version with the new feature and keep updating with each STS release until an LTS version becomes available."

5.3 Don't sit past end-of-support

Once an LTS line passes its EOL date, no further security patches are issued for it. From that point on, every newly disclosed CVE in Trino, the JDK, or a connector is unaddressed for your platform. Treat the EOL date as a hard deadline in your platform roadmap, not a soft target.

5.4 What about downgrades?

The policy intentionally says nothing about downgrades, and that's the right read: don't plan around them. Metadata, query history, and on-disk state are written by the engine version that produced them. The supported recovery path is rolling forward to a fixed patch level on the same line — that's what the -e.x patches exist for.

---

6. What gets backported (and what doesn't)

This is the most commonly misunderstood part of the policy, so it's worth being explicit:

The mental model is: LTS patches make a release safer, not newer. If you want newer behavior, you upgrade the line, not the patch level.

---

7. A quick FAQ

Can I run two SEP versions side-by-side during a migration? Yes — a common pattern is to bring up a new cluster on the target LTS, point a portion of workload at it, and decommission the old cluster once validation is done. Catalog metadata in Iceberg/Hive/Glue is shared across clusters, which makes blue/green upgrades practical.

Does an SEP version number guarantee feature parity with the same Trino number? The engine version matches, so yes for upstream Trino features. SEP also ships its own additions (security, connectors, the web UI, etc.); those are documented per release.

If I'm running, say, 443-e.x today, can I jump directly to 479-e.x? Technically you skip the intermediate LTS lines, but you don't get to skip their breaking changes. The required reading is the breaking-changes document for every line between current and target — that's where most upgrade pain hides.

Where does Starburst Galaxy fit in? Galaxy is the fully managed SaaS offering and is versioned and upgraded by Starburst itself — the LTS/STS model in this post applies specifically to self-managed SEP.

---

8. Takeaways

• SEP versions are Trino number + -e (STS) or Trino number + -e.x (LTS). Read the number, know what you have.
• LTS = 12 months of patches, at most one per quarter, with security and critical-defect backports. This is the default for production.
• STS = latest-only, no patches; useful when you need features ahead of the next LTS, at the cost of a continuous upgrade cycle.
• Plan one LTS-to-LTS upgrade per year, work through breaking changes line by line, and treat the EOL date as non-negotiable.
• New features never come as patches. If you need them, you move the line — there's no shortcut.

The version policy isn't bureaucracy; it's the contract that lets you keep a Trino-based platform stable for a year at a time. Use it that way.

— The Data Dynamics Team