Trinoとは？分散SQLクエリエンジンの仕組みとPresto・Sparkとの違い【Trino 484対応】

Trino（トリノ）は、データを1か所に集めずに、S3上のデータレイクやPostgreSQL・MySQLなどの複数のデータソースへSQLを投げて横断集計する分散クエリエンジンです。Facebookで生まれたPrestoから2019年に分岐し、2020年12月に現在の名前へ改称しました。ライセンスはApache License 2.0で、最新版は2026年10月15日公開のTrino 484です。

この記事では、Prestoとの違い、coordinatorとworkerの構成、Java 25が必要になった導入手順を整理したうえで、Trino 484とPostgreSQL 18を実際につないで取った実行計画から、どの条件がデータソース側へ押し下げられるのかを示します。CLIとPythonからの接続、ユーザーごとのアクセス制御、483から484へ上げるときに結果が変わるSQLも、実行結果つきで載せています。

まとめ：Trinoの要点

• Trinoはデータベースではなく、SQLを受けて各データソースから読み出して集計するクエリエンジンです。公式ドキュメントはOLTP（トランザクション処理）向けではないと明記しています。
• PrestoSQLが2020年12月27日にTrinoへ改称しました。Facebook側のPrestoDBはLinux Foundation傘下で別に開発が続いており、版番号の体系も別です（Trino 484とPrestoDB 0.299）。
• 構成は1台のcoordinatorと複数のworkerです。データソースへの接続はコネクタが担い、カタログ.スキーマ.テーブルの3階層でテーブルを指定します。
• サーバーの動作要件は64bit LinuxとJava 25（25.0.1以上）です。Java 21以前では起動しません。手元で試すならDockerの trinodb/trino イメージが最短です。
• PostgreSQLコネクタでは、整数列のGROUP BYは集計ごとPostgreSQLへ押し下げられましたが、text列のGROUP BYはWHERE句だけが押し下げられました。PostgreSQLのテーブルは1スプリットで読まれたので、大きなRDBのテーブルを結合すると読み出しがボトルネックになります。
• 長時間のバッチを落としたくない場合は、fault-tolerant execution（retry-policy=TASK など）を有効にします。既定は無効です。
• Trino 484ではJSON型とinterval型の挙動が変わりました。483と484で同じSQLを実行すると、hour(INTERVAL '36' HOUR) は12から36に、json_parse のキー順は並べ替えから入力順の保持に変わります。版を上げる前に、JSONやintervalを使うクエリの結果を比べてください。

Trinoの位置づけ：データを事前に集めずにSQLで横断する分析エンジン

Trinoはデータを自前で保存しません。クエリを受けるたびにコネクタ経由で各データソースから読み出し、結合・集計はTrinoのworkerのメモリ上で行います。公式ドキュメントのUse casesの章は、Trinoを汎用のリレーショナルデータベースと取り違えないよう、次のように書いています。

Trino is not a general-purpose relational database. It is not a replacement for databases like MySQL, PostgreSQL or Oracle.

つまり、業務アプリの更新処理を載せるデータベースの代わりにはなりません。向いているのは、テラバイト級のデータレイクへの対話的な分析クエリ、データを複製せずにRDBとデータレイクを1本のSQLで結合するフェデレーションクエリ、BIツールの背後で使うクエリ層の3つです。OLTPとOLAPの違いはOLTPとは？OLAPとの違いとAWSのOLAP基盤Redshift・Athenaの選び方で詳しく扱っています。

TrinoとPrestoの違い：2019年の分岐と2020年の改称

Prestoは2012年にFacebookのデータ基盤チームで、Martin Traverso、Dain Sundstrom、David Phillips、Eric Hwangの4人がHadoop上の巨大なデータウェアハウスを対話的に分析するために作ったエンジンです。

Trino公式ブログの改称告知（2020年12月27日）によると、2018年にFacebookがPrestoの経験がない社内開発者へコミット権を与える方針を決めたことをきっかけに、創設者のうち3人がFacebookを離れました。2019年1月に独立団体のPresto Software Foundationを作り、フォークをPrestoSQLとして開発します。その後FacebookはPrestoの商標を出願し、2019年9月にLinux Foundation傘下のPresto Foundationを設立しました。商標の条件で合意できず、PrestoSQLは2020年12月にTrinoへ改称しています。コードベースと財団（Trino Software Foundation）も同時に改名されました。

「presto sql」と「trino sql」の情報が混在するのはこの経緯のためです。2019年以降は別々に機能が追加されているので、新しく導入するならTrinoを、PrestoDBで組んだ既存環境との互換を優先するならPrestoDBを選ぶ、という分け方になります。

Trinoのアーキテクチャ：coordinator・worker・connector

coordinatorとworkerの役割分担

Trinoのクラスタは、クライアントからSQLを受けて解析・計画・スケジューリングを行うcoordinator 1台と、実際にデータを読み出して処理するworker複数台で構成されます。ノード間の通信はすべてHTTPです。どのノードも etc/config.properties の設定だけでcoordinatorにもworkerにもなります。公式ドキュメントの最小構成は次のとおりです。

# coordinator
coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
discovery.uri=http://example.net:8080

# worker
coordinator=false
http-server.http.port=8080
discovery.uri=http://example.net:8080

node-scheduler.include-coordinator=false はcoordinatorに処理を割り当てない設定です。大きなクラスタでcoordinatorに処理を載せると、スケジューリングと監視に使うはずのCPUとメモリが奪われるため、公式ドキュメントも専用マシンにすることを推奨しています。1台で試すときだけ true にします。性能は、workerを足して並列度を上げることで伸ばします。

カタログ・スキーマ・テーブルの3階層

Trinoからデータソースを見るには、etc/catalog/ にプロパティファイルを1つ置きます。ファイル名がカタログ名になり、connector.name で使うコネクタを指定します。以下は、TrinoとPostgreSQLを同じホストで動かした実行例のカタログ pg です。Dockerでは接続先をコンテナから到達できるホスト名に変更し、カタログファイルを /etc/trino/catalog にマウントします。

# etc/catalog/pg.properties
connector.name=postgresql
connection-url=jdbc:postgresql://localhost:55432/shop
connection-user=postgres
connection-password=

SQLではテーブルを pg.public.customer_segment のように「カタログ.スキーマ.テーブル」で指定します。同じPostgreSQLでもデータベースごとにカタログを分けられるので、本番と分析用レプリカを別カタログとして並べることもできます。

クエリがstage・task・splitに分かれる流れ

coordinatorはSQLを分散実行計画に変換し、ステージ（EXPLAINでは Fragment と表示）に分けます。各ステージはworker上のタスクとして並列に動き、タスクはデータソースを分割した単位であるスプリットを読みます。タスクの中では、スプリットを1つずつ処理するドライバーが並列に動き、ドライバーはテーブルの読み出し・フィルタ・集計などのオペレーターをつないで実行します。ステージ間の受け渡しはエクスチェンジで、既定では中間データをメモリ上でパイプライン的に流すので、中間結果をディスクへ書き出すMapReduce型と比べてディスクI/Oを減らせるため、対話的な分析に向いた設計です。その反面、ノードが1台落ちるとクエリ全体が失敗します。これを補うのが後述のfault-tolerant executionです。

Trinoの導入手順：Dockerとtarballの2通り

Dockerで最短に試す手順

公式のコンテナイメージ trinodb/trino にはサーバーとCLIの両方が入っています。タグを省略すると latest になるので、再現性が必要なら trinodb/trino:484 のように版を指定します。

docker run --name trino -d -p 8080:8080 trinodb/trino:484
docker exec -it trino trino
trino> SELECT count(*) FROM tpch.sf1.nation;

イメージにはサンプルデータを生成するTPC-Hカタログが入っているので、データソースを用意しなくてもクエリを試せます。docker ps の表示が (health: starting) から (healthy) に変われば起動完了です。Kubernetesで動かす場合は公式のHelmチャートが用意されています。

Trino 484からイメージの土台がRed Hat Hardenedのcore runtimeに変わり、grep や dnf、useradd が入っていません。起動スクリプト run-trino も削除されました。独自の node.properties をマウントしている場合は、Release 484のとおり node.id=${ENV:HOSTNAME} を書かないと、コンテナのホスト名をノードIDに使う動作が引き継がれません。イメージを継承して RUN dnf install などを足しているDockerfileも、484では作り直しが要ります。

tarballで立てる場合の要件と設定ファイル4種

サーバーを直接インストールする場合の要件は、64bitのLinuxと64bitのJava 25です。Trino 484のDeploying Trinoは次のように書いています。

Trino requires a 64-bit version of Java 25, with a minimum required version of 25.0.1 and a recommendation to use the latest patch version. Earlier versions such as Java 8, Java 11, Java 17, Java 21 or Java 24 do not work.

古いTrinoをJava 21で動かしている環境は、Trinoの版を上げる前にJDKの入れ替えが必要です。JDKはTrinoのテストに使われているEclipse Temurinが推奨されています。配布物は、全プラグイン入りの trino-server-484.tar.gz（約861MB）と、最小構成の trino-server-core-484.tar.gz（約292MB）の2種類です。core版を選んだ場合は、使うコネクタのプラグイン（trino-postgresql-484.zip など）を plugin/ 配下に展開して足します。macOSで試す場合、Intel Macでは bin/launcher がアーキテクチャ判定で止まることがあるので、bin/darwin-amd64/launcher start --etc-dir etc のように同梱のバイナリを直接指定します。

展開後に etc/ に置く設定ファイルは次の4種です。

node.environment はクラスタ内の全ノードで同じ値、node.id はノードごとに一意の値にします。起動は bin/launcher start、フォアグラウンドで動かすなら bin/launcher run です。ログの ======== SERVER STARTED ======== が起動完了の目印になります。

公式コネクタ37種の分類

Trino 484のドキュメントに載っているコネクタは37種です。用途で分けると次のようになります。

一方で、利用の少ないコネクタは削除が進んでいます。Accumuloは464、Kinesisは470、KuduとPhoenixは473、Verticaは480のリリースで削除されました。484でもCassandraコネクタがCassandra 4.0以上を必須にし、Hiveコネクタは新しく作るテーブルの既定の格納形式（hive.storage-format）がORCからPARQUETに変わっています。古い記事の設定例をそのまま使う前に、コネクタが現行版に残っているかを確認してください。

データレイク系のコネクタは、S3などのオブジェクトストレージ上のParquetやORCファイルを、HiveメタストアやIcebergのRESTカタログを通してテーブルとして読みます。テーブル形式の違いはオープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】、IcebergカタログをTrinoから使う設定はApache Polarisとは？IcebergカタログのRBACとDocker導入手順【1.7.0対応】で扱っています。

kintoneやSalesforceのような業務SaaS向けの公式コネクタはありません。接続方法には、データをS3やRDBへ書き出す方法、外部提供のコネクタを利用する方法、コネクタを自作する方法があります。外部コネクタは対象SaaSとTrinoの版への対応を確認します。Google Sheetsは公式コネクタがあり、connector.name=gsheets とサービスアカウントの認証情報、シート名とテーブル名の対応を書いたメタデータシートのIDを指定して使います。

異なるデータソースを1本のSQLで結合する実行例

ここからは、Trino 484（Java 25.0.4.1、1ノード構成）にTPC-HカタログとPostgreSQL 18.6のカタログ pg をつないで実行した結果です。PostgreSQL側には、データベース shop に顧客区分を持つ1,500行のテーブル customer_segment を作りました。

-- PostgreSQL（psqlでshopに接続して実行）
CREATE TABLE customer_segment (custkey bigint PRIMARY KEY, segment text NOT NULL);
INSERT INTO customer_segment
SELECT g, CASE WHEN g % 10 = 0 THEN 'premium' ELSE 'standard' END
FROM generate_series(1, 1500) g;

TPC-HとPostgreSQLのテーブルのJOIN

TPC-Hの注文テーブル（15,000行）と、PostgreSQLの顧客区分テーブルを結合して、区分ごとの注文数と売上を集計します。分析用ストレージへの事前移行や全件複製は不要で、カタログ名を変えることで別のデータソースのテーブルを同じSQLに並べられます。ただし、実行時には必要なデータをTrinoへ転送します。

SELECT s.segment, count(*) AS orders, round(sum(o.totalprice)) AS revenue
FROM tpch.tiny.orders o
JOIN tpch.tiny.customer c ON o.custkey = c.custkey
JOIN pg.public.customer_segment s ON c.custkey = s.custkey
GROUP BY s.segment
ORDER BY revenue DESC;

 segment  | orders |    revenue
----------+--------+---------------
 standard |  13485 | 1.911316129E9
 premium  |   1515 |  2.16080701E8
(2 rows)

プッシュダウンされる条件とされない条件

フェデレーションの性能は、WHEREや集計をどこまでデータソース側で済ませられるか（プッシュダウン）で決まります。PostgreSQLのログに log_statement=all を設定して、Trinoが実際に送ったSQLを確認しました。まず、text型の列 segment でGROUP BYした場合です。

-- Trinoに投げたSQL
SELECT segment, count(*) FROM pg.public.customer_segment
WHERE custkey <= 1000 GROUP BY segment;

-- PostgreSQLが受け取ったSQL（ログより）
SELECT "segment" FROM "shop"."public"."customer_segment" WHERE "custkey" <= $1

WHERE句は押し下げられましたが、集計はされていません。PostgreSQLからは条件に合う1,000行がそのまま返り、count(*)はTrino側で計算されています。同じテーブルに整数列 tier を足し（ALTER TABLE customer_segment ADD COLUMN tier int; のあと、premiumを1、standardを2に更新）、それでGROUP BYすると結果が変わりました。

-- PostgreSQLが受け取ったSQL（ログより）
SELECT "tier", "_pfgnrtd_0" FROM (SELECT "tier", count(*) AS "_pfgnrtd_0"
  FROM "shop"."public"."customer_segment" WHERE "custkey" <= $1 GROUP BY "tier") o

今度は集計ごとPostgreSQLへ渡り、返ってくるのは2行だけです。EXPLAINでも、前者は TableScan の上に Aggregate[type = PARTIAL] と Aggregate[type = FINAL] が残り、後者は TableScan[table = pg:Query[SELECT "tier", count(*) ...]] の1ノードにまとまっていました。

文字列の比較や並び順はデータソースごとに違うため、Trinoは結果の正しさを優先して、文字列が絡む操作の一部を押し下げません。PostgreSQLコネクタのドキュメントでも、CHARやVARCHARの列に対する >・<・BETWEEN などの範囲条件は押し下げないと明記されています（=、IN、!= は押し下げられます）。大きなRDBのテーブルを集計する場合は、GROUP BYや範囲条件に使う列を整数や日付にできないかを先に確認し、EXPLAINで TableScan に Query[...] が出ているかを見ます。

JDBC系テーブルの1スプリット読み出し

上のJOINの EXPLAIN ANALYZE では、TPC-Hの注文テーブルは Splits: 16 で並列に読まれていたのに対し、PostgreSQLのテーブルは Splits: 1 でした。JDBC系のPostgreSQLコネクタは、このテーブルを1スプリット、つまり1本の接続で読み出していました。workerを増やしてもこの読み出しは並列にならないので、大きなRDBのテーブルをそのまま結合するとここが律速になります。大きなテーブルは、あらかじめ条件で絞り込むか、Parquetに書き出してデータレイク系のコネクタから読むほうが、Trinoの並列性を活かせます。

書き込めるコネクタと書き込めないコネクタ

書き込みに対応するかどうかはコネクタによって決まります。TPC-Hカタログへ INSERT すると次のエラーになりました。

INSERT INTO tpch.tiny.nation VALUES (99, 'X', 0, 'x');
Query 20261017_171709_00013_e9vhj failed: This connector does not support inserts

一方、Memoryコネクタには CREATE TABLE memory.default.premium AS SELECT custkey FROM pg.public.customer_segment WHERE segment = 'premium' で150行を書き込めました。PostgreSQLへも書き込めますが、PostgreSQLコネクタのドキュメントによると方式は操作ごとに違います。INSERT は既定で一時テーブルに書いてから対象テーブルへ移し、insert.non-transactional-insert.enabled=true にすると直接書き込む代わりにロールバックできなくなります。MERGE は merge.non-transactional-merge.enabled=true のときだけ使え、例外時に一部だけ更新される可能性があります。ETLの本番処理を任せる前に、失敗時にどこまで書き込まれるかを確認しておく必要があります。

fault-tolerant execution：障害時のクエリ・タスク再実行設定

既定のTrinoは、実行中にworkerが落ちたりリソースが足りなくなったりするとクエリ全体が失敗し、手動でやり直すことになります。fault-tolerant executionでは中間データをスプールし、QUERYではクエリ全体を、TASKでは失敗したタスクを再実行します。設定は config.properties の retry-policy で、既定値は NONE（無効）です（Fault-tolerant execution）。メモリ不足で落ちる場合は、再実行の前に query.max-memory（クラスタ全体）と query.max-memory-per-node（ノードごと）の上限を見直します。ただし、この2つは retry-policy=TASK のクエリには適用されません。TASKでは、ノードへタスクを割り当てるときの見積もりに使う fault-tolerant-execution-task-memory（タスクごとの初期メモリ）を調整します。

TASK ではS3・GCS・Azure・HDFSなどに中間データを置くexchange managerの設定が必要になります。また、対応していないコネクタに対して有効にすると This connector does not support query retries で失敗します。Trino 484の時点で対応しているのは、BigQuery、Delta Lake、Hive、Iceberg、MariaDB、MongoDB、MySQL、Oracle、PostgreSQL、Redshift、SQL Serverの11種です。SQLの構文エラーのようなユーザー側の誤りは再実行の対象になりません。484では、TASK でスプールした中間データが失われた場合に、再試行の上限まで繰り返さず1回の再試行で失敗する動作に変わりました。

Trinoへの接続とアクセス制御：CLI・Python・ファイルベースの権限

CLI・Pythonクライアントの接続設定

Dockerの中から trino コマンドを叩く以外に、手元の端末やアプリケーションからHTTPでcoordinatorへ接続できます。以下の例は http-server.http.port=18080 で起動した検証環境に接続しています。前述のDocker起動例のままなら、CLIとPythonの接続先ポートは8080です。CLIは実行可能なjarとして配布されており、--server で接続先を、--user でユーザー名を渡します。--execute を付けると対話モードに入らず1文だけ実行して終わるので、シェルスクリプトやcronから使えます。

java -jar trino-cli-484 --server http://localhost:18080 --user analyst \
  --execute "SHOW CATALOGS"

Pythonからは公式の trino-python-client（PyPIのパッケージ名は trino、2026年10月時点の最新は0.340.0）を使います。DB-APIの形なので、ほかのデータベースドライバと同じく cursor() と execute() で書けます。クライアントは事前に python -m pip install trino==0.340.0 で入れておきます。上の実行例のPostgreSQLのテーブルを集計した結果が次のとおりです。

import trino

conn = trino.dbapi.connect(host="localhost", port=18080, user="admin",
                           catalog="pg", schema="public")
cur = conn.cursor()
cur.execute("SELECT segment, count(*) AS n FROM customer_segment GROUP BY segment ORDER BY segment")
print(cur.fetchall())
# [['premium', 150], ['standard', 1350]]

catalog と schema を接続時に渡すと、SQLの中ではテーブル名だけで書けます。json 型の列は、Pythonには '[1,2.50]' のような文字列で返ってくるので、Pythonの値として扱うなら json.loads() を通します。この例のJSON配列はリストになり、JSONオブジェクトは辞書になります。BIツールやJavaアプリからはJDBCドライバ（Maven Centralの io.trino:trino-jdbc、Trino本体と同じ484）を使い、URLは jdbc:trino://host:8080/catalog/schema の形になります。

ユーザー別のカタログアクセス制御

Trinoの権限は、誰かを確かめる認証と、何を許すかを決めるアクセス制御に分かれます。認証にはパスワードファイル、LDAP、OAuth 2.0、JWT、Kerberos、クライアント証明書などがあり、Authentication typesのとおり、どれもTLS（またはTLSを終端したリバースプロキシからの転送の許可）と、クラスタ内通信用の共有シークレットの設定が前提です。アクセス制御には、JSONファイルで規則を書く方式、Open Policy Agent、Apache Rangerを選べます。

次は、ファイルベースのアクセス制御で、admin にはすべてのカタログを、analyst にはTPC-Hの読み取りだけを許した設定です。etc/access-control.properties に access-control.name=file と security.config-file=etc/rules.json を書き、規則ファイルを置いてサーバーを再起動しました。

{
  "catalogs": [
    {"user": "admin", "catalog": ".*", "allow": "all"},
    {"user": "analyst", "catalog": "(tpch|system)", "allow": "read-only"}
  ]
}

Trino 484で --user を変えて実行した結果です。

-- analyst で SHOW CATALOGS
 Catalog
---------
 system
 tpch

-- analyst で PostgreSQLのテーブルを読む
Access Denied: Cannot access catalog pg

-- analyst で memory にテーブルを作る
Access Denied: Cannot access catalog memory

-- Analyst（先頭が大文字）で SHOW CATALOGS
 Catalog
---------
 system

許していないカタログは SHOW CATALOGS にも出ません。規則の user は正規表現で、大文字小文字を区別して照合されるため、Analyst ではどの規則にも当たらず、system だけが見えました。IdPから大文字混じりのユーザー名が届く環境では、規則側を (?i)analyst のように書く（この書き方に変えると Analyst でも tpch が見えるようになりました）か、user mappingでユーザー名をそろえます。Trino 484からは GRANT や REVOKE でもユーザー名が小文字に変換されなくなったので、同じ注意がSQLでの権限付与にも当てはまります。

この検証は認証を設定していないので、--user は自己申告です。誰でも admin を名乗れる状態なので、本番ではTLSと認証を先に設定し、そのうえでアクセス制御の規則を書きます。

Trino 484で変わった点：483から上げる前に確かめるSQL

Trino 484は、JSON型を作り直し、interval型の精度を広げた版です。Release 484には破壊的変更（breaking）の印が付いた項目が多く、同じSQLでも結果が変わるものがあります。Trino 483と484を同じJava 25で並べて起動し、同じSQLを実行した結果が次のとおりです。

interval型から時を取り出す hour() は、483では24で割った余りの12を返し、484では先頭のフィールドを丸ごと返す36に変わりました。json_parse は、483ではキーを並べ替えていましたが、484では入力の順序と重複キーをそのまま保ちます。JSON文字列を比較してデータの差分を検出しているETLや、時間の差を hour() で集計しているレポートは、上げた直後に結果が変わります。EXCLUDE 句は、移動平均から自分の行を除くような集計を1つのウィンドウ関数で書けるようにするものです。

SELECT x, sum(x) OVER (ORDER BY x ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING
                       EXCLUDE CURRENT ROW) AS neighbors
FROM (VALUES 1, 2, 3, 4) t(x);

 x | neighbors
---+-----------
 1 |         2
 2 |         4
 3 |         6
 4 |         3

このほか、リリースノートで影響が大きいのは次の3点です（Dockerイメージの変更は導入手順の章に書きました）。

• Hiveコネクタの既定の格納形式：hive.storage-format の既定値がPARQUETになりました。ORCのテーブルを作り続けたい場合はカタログに hive.storage-format=ORC を書きます。
• ファイルシステムキャッシュの設定場所：Hive・Iceberg・Delta Lakeの fs.cache.directories などは、カタログのファイルではなくクラスタ共通のキャッシュマネージャーに書く形に変わりました。カタログ側に残すのは fs.cache.enabled だけです。
• ユーザー名の大文字小文字：GRANT・REVOKE・SET AUTHORIZATION・CREATE SCHEMA でユーザー名を小文字に変換しなくなりました。ロール名は従来どおり小文字になります。

JSON型の変更では、JSON_SERIALIZE が予約語になったので、この名前の列やテーブルは二重引用符で囲む必要があります。483以前のクラスタを484へ上げるときは、本番のクエリログからJSON関数・interval・Hiveへの CREATE TABLE を含むSQLを抜き出し、2つの版で結果を比べてから切り替えます。

TrinoとSpark・BigQuery・Athenaの使い分け

Sparkとの違いは、ユーザーが書く処理の幅です。Sparkは分散処理の汎用フレームワークで、DataFrame APIによる変換、MLlibによる機械学習、ストリーム処理まで1つの基盤で扱います。TrinoはSQLだけに絞り、中間データをメモリ上でパイプライン的に流して対話的な応答を狙う設計です。データエンジニアが夜間のETLをSparkで書き、アナリストが同じデータレイクをTrinoで対話的に引く、という併用は珍しくありません。

Amazon Athenaは、Trinoを自分で運用せずにS3へSQLを投げるためのサービスです。AWSのドキュメントによると、Athena engine version 3はTrinoとPrestoの改良を継続的に取り込む方式に変わり、関数もTrinoを基盤にしています。ただし、Athenaで使える関数や構文はAWSが取り込んだ範囲に限られ、Trinoの最新版の機能がすぐ使えるとは限りません。Athenaの料金の考え方はAmazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減、SDKからのクエリ実行とフェデレーテッドクエリはAWS Athenaの実装：SDKでのクエリ実行とフェデレーテッドクエリ・Iceberg更新にまとめています。AWS上でTrino本体を使いたい場合はAmazon EMRを使い、EMR 7.14.0に含まれるTrinoは479-amzn-2です。

データが1台に収まる規模なら、クラスタを組まずに済むDuckDBのほうが手軽です。単体で動く分析エンジンとの違いはDuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説【1.5.6対応】、Rustで組み込むクエリエンジンはApache DataFusionとは？Rust製SQLクエリエンジンの実行計画と導入手順【2026年9月版】を参照してください。

Trinoを採用すべきでない場面

次の条件に当てはまる場合は、Trinoを入れても運用の手間に見合う効果が出にくいと判断します。

• 分析対象が1つのRDBに収まっている：まずPostgreSQLのリードレプリカへの直接接続を検討します。Trinoのクラスタを追加せずに済み、構成を単純に保てます。前述のとおりTrinoを挟んでも読み出しは1スプリットのままです。
• 更新系の処理を載せたい：TrinoはOLTP向けではありません。PostgreSQLへの書き込みも、INSERTの既定動作と非トランザクション設定、MERGEの制約を確認する必要があります。
• PostgreSQLの文字列列での範囲検索や集計が中心：既定設定や掲載した集計例では押し下げに制約があります。他の条件で十分に絞れない場合は転送行数が増えるため、実行計画で確認します。
• Java 25を入れられない環境：ホストの標準JDKを変更できなくても、Javaを同梱したTrinoのコンテナを利用できる場合があります。コンテナや別環境も使えないなら、Athenaなどのマネージドサービスを検討します。

逆に、データレイクと複数のRDBをまたいで分析したい、BIツールのクエリ層を1つにまとめたい、という要件ならTrinoが第一候補になります。BIツールからは、Trino公式のエコシステムページにGrafana（コミュニティ開発のデータソースプラグイン）、Power BI、Tableau、Looker、Metabaseの接続方法が載っています。Metabaseの構成はMetabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】で扱っています。Trinoを含むデータレイクの構成から決めたい場合は、一創のデータ分析基盤構築・MLOps構築支援で設計から相談を受けています。

Trinoに関するよくある質問

Trinoはデータベースですか？

いいえ。Trinoはデータを保存せず、各データソースから読み出して集計するクエリエンジンです。公式ドキュメントも、MySQLやPostgreSQLの代わりになる汎用のリレーショナルデータベースではなく、OLTP向けでもないと明記しています。

Trinoは無料で使えますか？

はい。Apache License 2.0のオープンソースで、商用利用も無料です。費用が発生するのはサーバーやクラウドの利用料と、Starburstなどの商用版、Amazon Athena・Amazon EMRなどのマネージドサービスを使う場合です。

Trinoの最新バージョンはいくつですか？

2026年10月時点の最新はTrino 484（2026年10月15日公開）です（Release 484）。JSON_SERIALIZE 関数やウィンドウ枠の EXCLUDE 句が追加された一方、JSON型やinterval型の結果が変わる破壊的変更も含まれます。480から484までの5版は2026年3月から10月に出ており、間隔は3週間から3か月です。導入時は公式のリリースノートで採用する版の変更点を確認してください。

TrinoとPrestoのどちらを選べばよいですか？

新しく導入するならTrinoが基本です。TrinoはPresto創設者3人が2019年に始めたPrestoSQLが2020年12月に改称したものです。PrestoDB（0.299）はLinux Foundation傘下で別に開発が続いているので、PrestoDBで組んだ既存環境との互換を優先する場合に選びます。

MySQLやSQL Server、Googleスプレッドシートにもつなげますか？

はい。MySQL、SQL Server、PostgreSQL、Oracle、BigQuery、Google Sheetsには公式コネクタがあり、etc/catalog/ にプロパティファイルを置けばカタログとして見えます。kintoneのような業務SaaS向けの公式コネクタはありません。kintoneのデータは、RDBやS3へ書き出してから公式コネクタで読むか、外部のコネクタを使います。

関連記事

• オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】
• Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理
• AWS Athenaの実装：SDKでのクエリ実行とフェデレーテッドクエリ・Iceberg更新
• Apache DataFusionとは？Rust製SQLクエリエンジンの実行計画と導入手順【2026年9月版】
• DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説【1.5.6対応】