ErrLookup › Background articles › Presto NOT_SUPPORTED error: what "not supported" means and how to fix it

Presto NOT_SUPPORTED error: what "not supported" means and how to fix it

NOT_SUPPORTED is a Presto error code raised when the engine or a connector (Hive, Iceberg, JDBC, Hudi, SingleStore) reaches an operation it deliberately does not implement — an unsupported type coercion, an unsupported SQL feature like USE, an unsupported compression codec, or a type without comparison or binding support. This page explains why Presto throws NOT_SUPPORTED, the most common triggers, and the general ways to work around it.

Distilled from 156 documented records across 3 repositories.

Background

NOT_SUPPORTED is not a crash; it is Presto telling you, at a specific and intentional checkpoint, that the operation you asked for is real but unimplemented for your exact combination of types, features, or configuration. PrestoException carries a code plus a message, and NOT_SUPPORTED is chosen (rather than GENERIC_INTERNAL_ERROR or INVALID) precisely when the failure is a known capability boundary, not a bug. Across the 156 documented records, the message text varies widely — "Unsupported coercion from %s to %s", "USE statement is not supported", "Unsupported column type", "createContext not supported" — but the code is the constant a developer actually sees in the client.

The checkpoints cluster into a few layers. At the type-system layer, many operations only work for types that implement equality or comparison: index-join predicates, histogram keys, and sorted page merges all call Type.equalTo or compareTo, and when a type lacks that operator the engine wraps the underlying NotSupportedException as NOT_SUPPORTED. At the storage/connector layer, type translation is the biggest source: Hive read-time coercions after ALTER TABLE support only a fixed transition matrix (integer upscaling, varchar<->integer, float->double, element-wise nested coercions), Parquet decoding distinguishes INT96 12-byte timestamps and short (<=8-byte) decimals, and JDBC/Hudi/SingleStore connectors reject column types their remote engines cannot represent or bind. At the SQL/planning layer, some statements and clauses are simply unimplemented — USE is unconditionally rejected, MV definitions with LIMIT or non-AND WHERE predicates are refused, and cross-catalog materialized views require legacy_materialized_views=false.

A third cluster is configuration and capability discovery. The ORC and temp-file writers throw NOT_SUPPORTED when handed an unsupported compression codec, DWRF encryption setting, or writer feature; the router rejects an unknown scheduler type; distributed procedures throw "createContext not supported" when a connector never implemented them; and the Hive metastore bridge refuses schema renames because the Thrift API cannot actually perform one. In these cases the error fires before or during setup, not mid-scan. A few records are even guard rails against ambiguity or corruption: "Multiple tables matched" fires when a JDBC lookup resolves to more than one remote table, and "Unexpected table present in Hive metastore" fires when a system-table-shaped name is found where it must never exist.

From the caller's side, NOT_SUPPORTED usually arrives during planning or statement setup rather than mid-scan, and the message names the offending type, feature, or value. The right response is almost never "retry": the engine means what it says. Either restate the query within the supported envelope (CAST to a supported type, rewrite the predicate, qualify the table name), change the configuration to a supported value, or physically rewrite your data/DDL so the unsupported case disappears. Which envelope applies is library- and connector-specific — the Hive coercion matrix, the SingleStore type mapping, and the MV rewrite whitelist all differ — so always read the message's named type or feature against the documented capabilities of the exact connector and Presto version you run.

Common causes

What usually fixes it

Documented occurrences

…and 136 more across the corpus — use search.

Honest provenance: generated on 2026-09-04 from AI-assisted analysis of the linked records. See how records are made.