Logo
Login
Start Trial
Request Demo
Trino connector

A BI layer for a query engine that already federates.

Knowi connects to a Trino coordinator with a hostname, a port, a catalog and, ideally, a schema, either through the UI or through the Cloud9Agent for clusters on your internal network. You then issue native Trino SQL against one or more catalogs and blend the result with other SQL and NoSQL sources.

Book a demo → Read the connector docs

Trino stays the distributed engine. Knowi turns its result sets into saved datasets, dashboards, alerts and embedded widgets.

data / datasources / trino connected
Query editor coordinator: trino-01 · port 8080
MySQLcatalog: mysql PostgreSQLcatalog: postgresql
SELECT m.member_id, m.plan, p.orders_30d, p.revenue_30d FROM mysql.users.members m JOIN postgresql.analytics.purchase_summary p ON p.member_id = m.member_id WHERE m.status = 'active'
member_idplanorders_30drevenue_30d
10041growth142,180.00
10042starter396.00
10043growth91,404.00
10044scale287,612.00
direct queryjoin runs in trinosave as dataset

Trino answers questions. It does not carry them.

Connecting

Point it at the coordinator.

Trino sits under Data Warehouses when you add a new datasource. Test Connection validates the settings before you save.

The catalog can be tpch, mysql, postgresql or anything else configured on your cluster. Schema is optional on the form, and the docs recommend setting it anyway.

New datasource trino
hostHostname or IP of the coordinator
port8080default
catalogmysqlrequired
schemausersoptional, recommended
usernameOptional
passwordOptional
propertiesSSL=true&SSLVerification=NONEoptional
test connection passed
Private clusters

No public route to the coordinator? Run the agent inside.

The cluster has to be reachable from Knowi's servers for the UI approach. If it is not, the Cloud9Agent runs inside your network and keeps the coordinator details local.

SSL and TLS settings are one of the four documented causes of connection failure, so verify them and the certificate configuration first.

Cloud9Agent config
typeTRINO
hosttrino-coordinator.internal
port8080
catalogpostgresqldefault catalog
schemaanalyticsoptional
useSSLtrueoptional
agent inside the network, no inbound route required
The boundary

Trino already joins across sources. So where does Knowi's join belong?

It is the first thing anyone running Trino asks, and two different mechanisms are in play. One runs in the engine. One runs on the results.

Layer 1 runs in trino
Trino coordinator
one statement, planned and distributed
MySQL mysqlcatalog
PostgreSQL postgresqlcatalog
tpchand any other catalog
mysql.users.members JOIN postgresql.analytics.purchase_summary

Knowi issues native Trino SQL to one or more catalogs, so a cross-catalog join stays inside Trino. The docs show exactly this query.

Layer 2 runs in knowi
Join on query results
in memory, disk swap for larger datasets
Trino Trino resultquery 1
MongoDB Elasticsearch REST API A source with no catalogquery 2
SQL and NoSQL datasources same source or disparate sources

Knowi joins the output of two queries, so it reaches sources Trino is not configured to see. That is a different operation, not a competing one.

If the source already has a catalog
Push the join into Trino.It is the engine built for it, and Knowi is issuing the SQL either way.
If it does not, or adding one means a cluster change
Connect the source to Knowi and join on the result.No cluster change for the sake of one report.
What the docs do not settle

Neither the Trino connector documentation nor the joins documentation defines a rule for which layer should own a given join, and neither documents predicate pushdown or cost-based routing between the two. Treat it as a configuration decision per dataset, not something the platform decides for you, and ask us to look at a specific workload rather than guess from this page.

The other side of the join

Sources Knowi connects directly.

A Trino result can be joined to any of these, whether or not the cluster has a catalog for them.

PostgreSQLPostgreSQL MySQLMySQL MongoDBMongoDB SnowflakeSnowflake ElasticsearchElasticsearch REST APIsREST APIs CassandraCassandra Google BigQueryBigQuery

PostgreSQL and MySQL appear on both sides of this page on purpose. The same system can be a Trino catalog or a Knowi datasource, which is exactly why the layer a join runs in is a decision rather than a default. See every supported datasource.

Beyond a result set

A saved dataset, not another query someone re-pastes.

Preview the query, then save it as a dataset that drives visualizations and dashboards instead of living in a client's scratch tab.

  • The visual builder generates SQL from tables picked in the schema explorer, where you browse catalogs, view column types and right-click for sample queries
  • The Query Editor takes native Trino SQL, including session properties such as distributed_join and query_max_memory
  • The AI Assistant generates a query from a description, explains an existing one, flags problems, and answers Trino-specific syntax questions

Three ways in, one dataset out.

Three ways to build the same query
Visual builder
Schema explorer→ Pick tables→ Generated SQL
browse catalogs · column types · right-click for sample queries
Query editor
Native Trino SQL→ Session properties
distributed_join · query_max_memory
AI assistant
Plain English→ Query, explained
generate · explain · flag problems · trino syntax
save as dataset
Execution strategy

Live or cached, chosen per query.

Direct query executes in real time against Trino. Cached data stores results for faster dashboard loading.

That is the lever for a dashboard that would otherwise re-run a distributed query every time somebody opens it.

Data execution strategy
Direct query
Dashboard view→ Trino coordinator→ Result
executes in real time against trino
Cached
Dashboard view→ Stored result
stored results for faster dashboard loading
set per query
From the documentation

Two things the docs tell you to do, and one list to keep.

Best practice

Always specify a schema

It is optional on the form and recommended in practice, for performance and to avoid scanning all schemas.

Best practice

Push predicates down

Use appropriate filters in the query rather than filtering after the fact, so the work happens where the data is.

Troubleshooting

Four ways a connection fails

  1. The cluster is not reachable from Knowi's servers or the agent
  2. Authentication
  3. A catalog that does not exist or is not configured in Trino
  4. SSL or TLS settings
Fit

Where this fits, and where it does not.

Good fit

Trino answers questions for a group larger than the people who write SQL against it, some of what you need sits outside the configured catalogs, and you want the output embedded in your product or reaching people as dashboards and alerts rather than query results.

Weaker fit

Every source you care about already has a catalog, your users are engineers content in a SQL client, and the Web UI covers your monitoring. Trino is doing the job and a layer on top is overhead. Knowi earns its place when the answer has to leave the cluster's audience.

The options

Three ways to work with data behind Trino.

All three are reasonable. They diverge once the audience grows.

SQL client and the Trino Web UI
A BI tool treating Trino as one JDBC source
Knowi on Trino
Who can ask a question
Whoever writes Trino SQL and has cluster access.
Anyone, once someone has modelled the tables for them.
Visual builder over the schema explorer, plain English through the AI Assistant, or native SQL.
A source with no Trino catalog
Add a catalog and redeploy, or leave it out.
Usually a second connection and a second report.
Connected directly to Knowi and joined to the Trino result in one dataset.
Where the join runs
In Trino, which is the point of it.
Varies by tool, and often not visible to you.
Your choice: cross-catalog SQL runs in Trino, cross-source joins run on results in Knowi or on the agent.
Repeat runs of the same query
Re-executed every time someone asks.
Depends on the extract or cache model.
Direct query in real time, or cached results for faster dashboard loading, chosen per query.
A cluster on an internal network
You are already inside it.
Needs a route, a tunnel or a copy.
Cloud9Agent runs inside the network with type=TRINO and the coordinator details local.
Analytics inside your own product
Not what either tool is for.
Generally a separate licence and a separate build.
The same dataset is embeddable and white-labelled, with per-tenant filtering.
Questions

Trino connector questions.

What do I need to connect Knowi to Trino?

A datasource name, the hostname or IP of your Trino coordinator, the port it listens on, and the catalog to connect to. Port defaults to 8080. Schema is optional but recommended. Username, password and connection properties are optional. Test Connection validates the settings before you save.

If Trino already federates queries, what does Knowi add?

Trino plans and distributes a single SQL statement across the catalogs it is configured for, and Knowi issues that native Trino SQL rather than replacing it. Knowi adds the layer above the engine: saved datasets, visual query building over the schema explorer, dashboards, alerts, cached or live execution per query, and embedding in your own application.

Can I join a Trino result to a source Trino has no catalog for?

Yes. Knowi joins the same or disparate SQL and NoSQL datasources by joining the results of two queries, so a source Knowi connects to directly can be joined to a Trino query. One caveat: the documentation does not define a rule for which layer should own a given join, so it is a configuration decision per dataset.

Can Knowi query a Trino cluster on an internal network?

Yes, through the Cloud9Agent. The documentation states the cluster must be accessible from Knowi's servers for the UI approach, and directs internal clusters to the agent. Agent configuration takes type=TRINO, the coordinator host, the port and a default catalog, with schema, credentials and SSL settings optional.

Does Knowi run native Trino SQL or its own dialect?

Native Trino SQL, against one or more catalogs. The Query Editor takes the statement as written, including session properties such as distributed_join and query_max_memory. The visual builder generates the SQL for you from tables picked in the schema explorer.

How do I connect Knowi to Trino over SSL?

Pass the SSL settings in the connection properties field, for example SSL=true&SSLVerification=NONE. On the Cloud9Agent there is a useSSL parameter alongside the properties string. SSL and TLS errors are one of the four documented causes of connection failure, so verify the settings and the certificate configuration first.

Put a BI layer on your Trino cluster.

Point Knowi at the coordinator, or run the Cloud9Agent inside the network. Keep the native SQL, and give the results an audience.

Book a demo → Connector documentation

Knowi also connects Snowflake and PostgreSQL, and the same dataset can be embedded in your own product. See every supported datasource.