Plugins#
Trino uses a plugin architecture to extend its capabilities and integrate with various data sources and other systems. Trino includes many plugins as part of the binary packages - specifically the tarball and the Docker image.
Plugins implement some of the following capabilities:
Additional types and global functions
Block encodings
Resource group configuration managers
Session property configuration managers
Exchange managers
Spooling managers
All plugins are optional for your use of Trino because they support specific
functionality that is potentially not needed for your use case. Plugins are
located in the plugin folder of your Trino installation and are loaded
automatically during Trino startup.
Download#
Typically, downloading a plugin is not necessary because Trino binaries include many plugins as part of the binary package. Every Trino release publishes each plugin as a ZIP archive to GitHub. Refer to List of plugins for details.
The specific name is derived from the Maven coordinates of each plugin as
defined in the pom.xml of the source code for the plugin.
For example, the PostgreSQL connector plugin can be found in the
plugin/trino-postgresql directory, and the pom.xml file contains the
following identifier section:
<parent>
<groupId>io.trino</groupId>
<artifactId>trino-root</artifactId>
<version>481</version>
<relativePath>../../pom.xml</relativePath>
</parent>
<artifactId>trino-postgresql</artifactId>
<packaging>trino-plugin</packaging>
The coordinates translate into a path to the ZIP archive on GitHub releases. Use this URL to download the plugin.
For example, the PostgreSQL connector plugin can be downloaded at
https://github.com/trinodb/trino/releases/download/481/trino-postgresql-481.zip
Availability of plugins from other projects and organizations varies widely, and may require building a plugin from source.
When downloading a plugin you must ensure to download a version of the plugin that is compatible with your Trino installation. Full compatibility is only guaranteed when using the same Trino version used for the plugin build and the deployment, and therefore using the same version is recommended. Use the documentation or the source code of the specific plugin to confirm and refer to the SPI compatibility notes for further technical details.
Installation#
To install a plugin, extract the ZIP archive into a directory in the plugin
directory of your Trino installation on all nodes of the cluster. The directory
contains all necessary resources.
For example, for a plugin called example-plugin with a version of 1.0,
extract the example-plugin-1.0.zip archive. Rename the resulting directory
example-plugin-1.0 to example-plugin and copy it into the plugin directory
of your Trino installation on all workers and the coordinator of the cluster.
Note
Every Trino plugin must be in a separate directory underneath the plugin
directory. Do not put JAR files directly into the plugin directory. Each
plugin directory should only contain JAR files. Any subdirectories and other
files are ignored.
By default, the plugin directory is the plugin directory relative to the
directory in which Trino is installed, but it is configurable using the
configuration variable plugin.dir with the launcher. The Docker
image uses the path /usr/lib/trino/plugin.
Restart Trino to use the plugin.
The trino-packages project contains example projects to create a tarball and Docker image with a selection of plugins by installing only the desired plugins.
Removal#
Plugins can be safely removed if the functionality is not needed or desired on your Trino cluster. Use the following steps for a safe removal across the cluster:
Shut down Trino on all nodes.
Delete the directory in the
pluginfolder of the Trino installation on all nodes.Start Trino on all nodes.
Refer to the List of plugins for relevant directory names.
For repeated deployments, you can remove the plugin from the binary package for your installation by creating a custom tarball or a custom Docker image.
Development#
You can develop plugins in your own fork of the Trino codebase or a separate project. Refer to the Developer guide for further details.
List of plugins#
The following list of plugins is available from the Trino project. They are included in the build and release process and the resulting the binary packages.
Plugin directory |
Description |
Download |
|---|---|---|
ai-functions |
||
bigquery |
||
blackhole |
||
cassandra |
||
clickhouse |
||
delta-lake |
||
druid |
||
duckdb |
||
elasticsearch |
||
example-http |
||
exasol |
||
exchange-filesystem |
Fault-tolerant execution exchange file system |
|
exchange-hdfs |
Fault-tolerant execution exchange file system for HDFS |
|
faker |
||
functions-python |
||
geospatial |
||
google-sheets |
||
hive |
||
http-event-listener |
||
http-server-event-listener |
HTTP server event listener |
|
hudi |
||
iceberg |
||
ignite |
||
jmx |
||
kafka |
||
kafka-event-listener |
||
lakehouse |
||
loki |
||
mariadb |
||
memory |
||
ml |
||
mongodb |
||
mysql |
||
mysql-event-listener |
||
opa |
||
openlineage |
||
opensearch |
||
oracle |
||
password-authenticators |
Password authentication |
|
pinot |
||
postgresql |
||
prometheus |
||
ranger |
||
redis |
||
redshift |
||
resource-group-managers |
||
session-property-managers |
||
singlestore |
||
snowflake |
||
spooling-filesystem |
Server side support for Spooling protocol |
|
sqlserver |
||
teradata-functions |
||
thrift |
||
tpcds |
||
tpch |