Skip to main content
Version: 1.3.1

Trino Connector Configuration

Introduction​

PropertyTypeDefault ValueDescriptionRequired
connector.namestring(none)The connector.name defines the type of Trino connector, this value is always 'gravitino'.Yes
gravitino.metalakestring(none)The gravitino.metalake defines which metalake in Gravitino server the Trino connector uses. The value needs to be a valid name, Trino connector can detect and load the metalake with catalogs, schemas and tables once created and keep in sync. When unset, the catalogs of every metalake are loaded, the system tables report every metalake, and the METALAKE argument of the stored procedures is required.No
gravitino.uristringhttp://localhost:8090The gravitino.uri defines the connection URL of the Gravitino server, the default value is http://localhost:8090. Trino connector can detect and connect to Gravitino server once it is ready, no need to start Gravitino server beforehand.No
trino.jdbc.userstringadminThe jdbc user name of current Trino.NO
trino.jdbc.passwordstring(none)The jdbc password of current Trino.NO
trino.jdbc.ssl.enabledboolean(derived)Whether the internal JDBC connection to the Trino coordinator uses TLS. If not set, it is derived from the scheme of the Trino discovery.uri, so a coordinator whose discovery.uri is https://... needs no explicit setting.No
trino.jdbc.ssl.truststore.pathstring(none)Path of the truststore holding the Trino coordinator certificate. If omitted, the default JVM truststore is used. Requires TLS, which is enabled automatically for an HTTPS discovery.uri or explicitly with trino.jdbc.ssl.enabled=true, and a trino.jdbc.ssl.verification other than NONE.No
trino.jdbc.ssl.truststore.passwordstring(none)Password of the truststore configured by trino.jdbc.ssl.truststore.path. Requires TLS and trino.jdbc.ssl.truststore.path, otherwise the connector fails to start.No
trino.jdbc.ssl.truststore.typestring(none)Type of the truststore, for example JKS or PKCS12. If omitted, the default JVM truststore type is used. Requires TLS and trino.jdbc.ssl.truststore.path, otherwise the connector fails to start.No
trino.jdbc.ssl.keystore.pathstring(none)Path of the keystore holding the client certificate presented to the coordinator, for coordinators that require mutual TLS. Requires TLS, which is enabled automatically for an HTTPS discovery.uri or explicitly with trino.jdbc.ssl.enabled=true, and a trino.jdbc.ssl.verification other than NONE. See the note on mutual TLS below.No
trino.jdbc.ssl.keystore.passwordstring(none)Password of the keystore configured by trino.jdbc.ssl.keystore.path. Requires TLS and trino.jdbc.ssl.keystore.path, otherwise the connector fails to start.No
trino.jdbc.ssl.keystore.typestring(none)Type of the keystore, for example JKS or PKCS12. If omitted, the default JVM keystore type is used. Requires TLS and trino.jdbc.ssl.keystore.path, otherwise the connector fails to start.No
trino.jdbc.ssl.verificationstringFULLCertificate verification mode of the internal JDBC connection: FULL, CA or NONE. Any value other than FULL requires TLS, which may be derived from an HTTPS discovery.uri. NONE disables certificate verification entirely and should only be used for troubleshooting.No
trino.jdbc.rolesstring(none)Session roles applied to the internal JDBC connection, for example system:sysadmin. Required by deployments that only allow CREATE CATALOG with a privileged role.No
trino.jdbc.properties.string(none)The configuration key prefix for raw Trino JDBC driver properties, see Connecting to a TLS-enabled coordinator.No
gravitino.metadata.refresh-interval-secondsinteger10The gravitino.metadata.refresh-interval-seconds defines the interval in seconds to refresh metadata from Gravitino server, the default value is 10 seconds.No
gravitino.trino.skip-version-validationbooleanfalseThe gravitino.trino.skip-version-validation defines whether to skip Trino version validation. Gravitino supports Trino versions between 435 and 478. If this option is true, unsupported Trino versions can still be used, but compatibility is not guaranteed.No
gravitino.client.string(none)The configuration key prefix for the Gravitino client config.No
gravitino.trino.skip-catalog-patternsstring(none)The gravitino.trino.skip-catalog-patterns defines a comma-separated list of catalog name regex patterns that should be excluded from loading. For example, test_.*, .*_tmp excludes all catalogs starting with test_ or ending with _tmp.No
gravitino.catalog-name-with-metalakebooleanfalseIf true, multi-metalake mode is enabled: every metalake is loaded and catalogs are identified by <metalake_name>.<catalog_name>. If false, catalogs are identified by <catalog_name>; when several metalakes are loaded and two of them have a catalog with the same name, only one of them is registered, in the order the server lists the metalakes, and the other is reported as FAILED in gravitino.system.catalog_status. Which one wins is not guaranteed to be stable, so set this to true when catalog names collide.No
gravitino.use-single-metalakebooleantrueDeprecated, use gravitino.catalog-name-with-metalake instead. false is equivalent to gravitino.catalog-name-with-metalake=true. Ignored when gravitino.catalog-name-with-metalake is set.No
gravitino.iceberg.rest-routing-enabledbooleantrueWhether non-REST lakehouse-iceberg catalogs must be routed through the Gravitino Iceberg REST server. When enabled, a catalog is not registered until discovery succeeds or gravitino.iceberg.rest-uri is configured. Set this to false to retain legacy catalog-backend translation and skip discovery.No
gravitino.iceberg.rest-uristring(none)The endpoint of the Gravitino Iceberg REST server (IRC). It is discovered automatically from the Gravitino server for each loaded metalake; set this only to override the discovered value. When available, eligible lakehouse-iceberg catalogs are loaded through IRC, enabling credential vending.No
gravitino.iceberg.rest-catalog.string(none)Prefix for properties passed to the internal Trino Iceberg REST catalog. The prefix is rewritten to iceberg.rest-catalog.. The uri, warehouse, and prefix keys are reserved and derived by the connector.No

To configure the Gravitino client, use properties prefixed with gravitino.client.. These properties will directly passed to the Gravitino client.

Note: Invalid configuration properties will result in exceptions. Please see Gravitino Java client configurations for more support client configuration.

When upgrading a deployment that does not provide an Iceberg REST endpoint, either configure gravitino.iceberg.rest-uri or set gravitino.iceberg.rest-routing-enabled=false to retain the legacy catalog-backend translation. Otherwise, non-REST lakehouse-iceberg catalogs remain unregistered until discovery succeeds. See Iceberg catalog.

Qualified catalog names (gravitino.catalog-name-with-metalake=true) are supported on Trino connector versions 435-445 and 469-478. On versions 446-468, a warning is logged and the connector initializes, but the mode is not fully supported and some operations may fail.

Note: gravitino.iceberg.rest-uri is the default endpoint for every loaded metalake. Since a single Iceberg REST server serves exactly one metalake, override it per metalake with gravitino.iceberg.rest-uri.<metalake_name> when several metalakes are loaded.

Connecting to a TLS-enabled coordinator​

The Gravitino Trino connector registers catalogs by connecting back to the Trino coordinator over JDBC and running CREATE CATALOG / DROP CATALOG. This connection is established when the connector starts and is reused by the metadata refresh loop, so it must be configured for the coordinator's own TLS and authorization settings.

connector.name=gravitino
gravitino.metalake=metalake
gravitino.uri=http://localhost:8090

# The internal JDBC connection to the coordinator.
trino.jdbc.user=admin
trino.jdbc.password=YourSecureTrinoPassword
trino.jdbc.ssl.truststore.path=/etc/trino/truststore.jks
trino.jdbc.ssl.truststore.password=YourSecureTruststorePassword
# Required when the deployment only allows CREATE CATALOG with a privileged role.
trino.jdbc.roles=system:sysadmin

trino.jdbc.ssl.enabled may be omitted when the Trino discovery.uri uses the https scheme, as it is derived from that scheme by default. When discovery.uri omits the port, the default port of its scheme is used, that is 443 for https and 80 for http.

The trino.jdbc.ssl.* configurations are only meaningful on a TLS-enabled connection. Setting any of them while TLS is disabled fails the connector at startup rather than being silently ignored, so a misconfigured truststore never degrades into a plaintext connection. Likewise, the truststore password and type require a truststore path, and the keystore password and type require a keystore path: without one the driver falls back to its default, which they would not apply to.

If the coordinator certificate is signed by a CA the JVM does not trust, import it into a truststore and point trino.jdbc.ssl.truststore.path at it:

# Export the coordinator certificate, then import it into a dedicated truststore.
openssl s_client -showcerts -connect coordinator.example.com:8443 </dev/null \
| openssl x509 -outform PEM > coordinator.pem
keytool -importcert -noprompt -alias trino-coordinator -file coordinator.pem \
-keystore /etc/trino/truststore.jks -storepass YourSecureTruststorePassword
caution

trino.jdbc.ssl.verification=NONE disables certificate verification completely and exposes the connection to man-in-the-middle attacks. Use it only for troubleshooting; import the coordinator certificate into a truststore instead.

The trino.jdbc.* properties are used by the coordinator only. They are never copied into the catalogs the connector creates, so the credentials they hold do not reach the generated CREATE CATALOG statements or the Trino catalog properties files.

Mutual TLS and certificate authentication​

A coordinator that requires mutual TLS also expects a client certificate. Point trino.jdbc.ssl.keystore.path at the keystore holding it:

trino.jdbc.ssl.keystore.path=/etc/trino/client.p12
trino.jdbc.ssl.keystore.password=YourSecureKeystorePassword
note

The mutual TLS configuration is provided for completeness and has not been verified against a coordinator that requires client certificates.

Trino can also be configured with http-server.authentication.type=CERTIFICATE, where the client certificate itself is the login and the coordinator derives the username from the certificate subject. The connector does not support that authentication type today: it always authenticates with trino.jdbc.user, so a coordinator configured this way rejects the internal JDBC connection.

Passing arbitrary JDBC driver properties​

Any Trino JDBC driver property that has no dedicated configuration can be passed through with the trino.jdbc.properties. prefix. The prefix is stripped and the remainder is handed to the driver verbatim, overriding the value derived from the dedicated trino.jdbc.* configurations:

trino.jdbc.properties.KerberosRemoteServiceName=trino
trino.jdbc.properties.SSLKeyStorePath=/etc/trino/client.p12
trino.jdbc.properties.SSLKeyStorePassword=YourSecureKeystorePassword

Properties passed through this prefix are handed to the driver without validation, unlike the dedicated trino.jdbc.* configurations. An unknown name or an invalid value therefore surfaces as a driver error when the connection is established, not as a configuration error.

See the Trino JDBC driver documentation for the full list of supported property names.

Authentication​

The Gravitino Trino connector supports authenticating to the Gravitino server using Simple, Basic, OAuth, and Kerberos authentication. For detailed authentication configuration, refer to Trino Connector Authentication.