Upgrading Trino OSS in 2026: Breaking Changes from Release 479 to 484

Trino has no long-term-support line. Each community release can remove properties, change defaults or reject configuration that worked before, and the release notes are the only notice. Between December 2025 and October 2026, releases 479 to 484 contained an unusually dense set of breaking changes: a new Java baseline, the end of legacy object-storage support, new S3 authentication rules, a new default Web UI and a reworked Docker image.

This article groups those changes by the part of the platform they affect, and sets out an upgrade sequence for teams running Trino OSS on Kubernetes or virtual machines. It covers community releases only. Starburst Enterprise follows its own release and support schedule.

Why this upgrade window needs a plan

The Trino release notes index lists six releases in this window: 479 (14 December 2025), 480 (24 March 2026), 481 (11 May 2026), 482 (25 June 2026), 483 (17 July 2026) and 484 (15 October 2026). Each one has a “Breaking changes” marker on individual items rather than a single migration guide.

Three things make this window different from routine upgrades:

• Runtime: the Java requirement moved, so the base image or host packages change, not only the Trino artifact.
• Storage access: legacy Hadoop-based access to S3, GCS and Azure was removed, so many catalog files must be rewritten.
• Behaviour: some SQL semantics changed, such as char to varchar coercion, which can alter query results without an error.

A team that skips several releases inherits all of these at once. The safest approach is to read every release note between the current and target versions, not only the target.

Runtime and packaging changes

The Trino 479 release notes state, as a breaking change, “Require JDK 25 to build and run Trino.” The deployment documentation now requires a 64-bit Java 25 runtime with a minimum of 25.0.1, and lists earlier Java versions as unsupported. Hosts or images that still ship Java 21 or 24 must change before the upgrade.

The Trino 484 release notes change the official Docker image in several ways:

• The base image moves to a Red Hat hardened runtime image, and the ppc64le image is removed.
• The run-trino script is removed. Custom entrypoints that called it need updating.
• Deployments that supply their own node.properties must set node.id=${ENV:HOSTNAME}.

Teams that build derived images, or mount configuration through a Helm chart, should rebuild and test the image itself before touching catalogs. Image changes tend to surface as startup failures, which are easy to see but block everything else.

Object storage: native file systems only

This is the change most likely to break a lakehouse catalog. The Trino 481 release notes remove legacy support for Azure, GCS, IBM COS, S3 and S3-compatible storage in the Delta Lake, Hive, Iceberg and Lakehouse connectors, and state that fs.hadoop.enabled applies only to HDFS.

The object storage documentation describes the replacement: native implementations for Azure Storage, Google Cloud Storage, S3 and local file systems, each enabled explicitly. For S3, fs.s3.enabled=true turns on the native implementation, which is off by default. The S3 file system page includes a migration section that maps legacy properties to native ones:

Legacy property	Native property
hive.s3.aws-access-key	s3.aws-access-key
hive.s3.aws-secret-key	s3.aws-secret-key
hive.s3.endpoint	s3.endpoint (with the https:// prefix)
hive.s3.region	s3.region
hive.s3.max-connections	s3.max-connections

The mapping is not purely mechanical. Endpoints for S3-compatible stores, path-style access and TLS trust need to be tested against the real object store, because a catalog that loads can still fail on its first read. Treat each catalog file as a small migration with its own test query.

Authentication and security changes

Several releases tighten how Trino authenticates to storage and to identity providers:

• S3 IAM roles (483): the Trino 483 release notes state that setting s3.iam-role now requires s3.auth-type=IAM_ROLE, and remove s3.use-web-identity-token-credentials-provider in favour of s3.auth-type=WEB_IDENTITY. The S3 page lists the supported values as ANONYMOUS, DEFAULT, IAM_ROLE and WEB_IDENTITY.
• GCS (479): unauthenticated access is no longer allowed when the GCS authentication type is SERVICE_ACCOUNT.
• Delta Lake on S3 (479): writes require the PutObjectTagging permission unless conditional writes for the transaction log are disabled. IAM policies may need a new action.
• OAuth 2.0 (480): the deprecated deprecated.http-server.authentication.oauth2.groups-field property is removed.
• User names (484): GRANT, REVOKE, SET AUTHORIZATION and CREATE SCHEMA now preserve the case of user names. Role names are still lowercased. Access-control rules and scripts that relied on lowercasing should be reviewed.

Release 484 also adds OAuth 2.0 client credentials support in the CLI and JDBC driver. That is useful for service accounts, but it is a new capability to adopt deliberately, not a required change.

SQL behaviour and connector changes

Some changes do not stop a cluster from starting. They change what queries return or which queries run. These deserve the most testing, because nothing fails loudly.

• Character coercion (482): the Trino 482 release notes state that a char value now coerces to varchar with trailing spaces removed. The temporary property deprecated.legacy-varchar-to-char-coercion restores the previous behaviour while queries are fixed.
• Pushdown on SQL Server and MySQL (482): inequality and range predicates on character columns are no longer pushed down. A DELETE or UPDATE on SQL Server that relied on that pushdown will now fail.
• Iceberg metadata tables (482 and 484): the lower_bounds and upper_bounds columns in $files became typed row values, and timestamps in $snapshots, $history and $metadata_log_entries are returned in UTC from 484. Monitoring queries over these tables may need rewriting.
• JSON limits (484): JSON values with more than 1,024 nested arrays and objects are rejected, as is input with overflowing exponent-form numbers.
• Hive default (484): the default hive.storage-format becomes PARQUET. New tables created without an explicit format will change.
• Removed connectors and integrations: the Vertica connector is removed in 480, Alluxio-backed exchange storage and Alluxio file system support are removed in 482, and the Cassandra connector requires Cassandra 4.0 or later in 484.

Release 483 also makes the redesigned Web UI the default at /ui, with the previous UI moved to /ui/legacy and disabled unless web-ui.legacy.enabled is set. Operators and support runbooks that reference screens in the old UI should be updated.

Plugin authors face SPI changes in most of these releases, including bit-packed validity bitmaps for block nulls in 483. Custom connectors and functions must be rebuilt and tested against the target release.

What the window adds, and what to adopt later

The same releases add capabilities worth planning for once the upgrade is stable. Examples from the release notes include a number type (480), the PIVOT clause (483), a cluster-wide file system cache shared by all catalogs (484), and refreshable vended credentials for the Iceberg REST catalog (481). Iceberg format version 3 support also grows across 480, 481, 482 and 484, and the Iceberg connector documentation still describes it as experimental.

Separate the upgrade from adoption. Upgrade with feature flags at their defaults and existing tables unchanged, confirm behaviour, then enable new features one at a time. Mixing the two makes regressions hard to attribute.

An upgrade sequence that limits surprises

1. Inventory. Record the current release, Java version, image source, every catalog file, every custom plugin and every client driver version.
2. Read every release note between the current and target releases. Extract each breaking item into a list with an owner.
3. Rebuild the runtime. Produce a Java 25 image or host build and confirm the coordinator and workers start with an empty catalog set.
4. Migrate catalogs one by one. Convert legacy hive.s3.*, hive.gcs.* and hive.azure.* properties, set s3.auth-type where roles are used, and run a read and a write test per catalog.
5. Replay representative queries. Compare results, not only success, for queries that use char columns, JSON functions, Iceberg metadata tables and federated pushdown.
6. Check access control. Confirm that grants and rules behave correctly with case-preserved user names.
7. Update clients and runbooks. Upgrade JDBC drivers and the CLI where needed, and update Web UI references.
8. Cut over with a rollback path. Keep the previous image and configuration available. Avoid table-level changes, such as format-version upgrades, until the new release is accepted, because those cannot be undone by redeploying.

Some teams choose to stop on an intermediate release, such as 481, to separate the storage migration from later changes. That is a reasonable trade-off if the intermediate release still receives the fixes the team needs. Note that Trino community fixes land in new releases, not as patches to old ones.

How Bassirah can help

Bassirah provides independent engineering support for Trino OSS: we can review release notes against your configuration, migrate catalogs to native file systems and rehearse the upgrade in a non-production environment. Upstream fixes follow the community’s timeline, as described in our open-source support model. For larger platform changes, see migration and modernization.