Trino Query UI

A reusable React component as a query interface for the SQL query engine Trino. Browse connected catalogs, write SQL queries, execute the queries and inspect result data all in a web application connected to your Trino cluster.

The component can be embedded into any React application and configured to proxy requests to a local or remote Trino cluster.

Warning

This package is under heavy development and is not yet recommended for production workloads. Treat the current release as an early-stage demo; production-ready builds and documentation are planned.

Implementation details:

• React TypeScript project with Vite
• Uses Node.js v24+
• Monaco editor + ANTLR parser using the Trino language

Features

• Browse metadata about catalogs, schemas, tables, and more
• Search across catalogs
• Set queries session context.
• Inspect data with generated queries
• Preview sample data
• Write queries manually with schema-aware SQL syntax completion and highlighting
• Use multiple query tabs
• View schema information in SQL queries via mouse-over hovering
• Format SQL queries in the editor
• Copy result set table data to the clipboard
• Monitor query processing across the Trino cluster

See details in the demo animation.

Installation

npm install trino-query-ui

Quick start

import { QueryEditor } from 'trino-query-ui'
import 'trino-query-ui/dist/index.css'

function MyTrinoApp() {
  return <QueryEditor theme="dark" height={800} />
}

export default MyTrinoApp

Building and shipping in Trino

The Query UI builds just like the existing UI in Trino.

1. Build the TypeScript into Javascript and CSS
2. Copy the distributable path into Trino.
3. Modify Trino to respond to the query ui path.

Building for integration

cd precise
npm install
npm run build

Copying into Trino

mkdir -p $TRINO_HOME/core/trino-main/src/main/resources/query_ui_webapp/
cp -r dist/* $TRINO_HOME/core/trino-main/src/main/resources/query_ui_webapp/

Modifying Trino to respond to /query/

Modify $TRINO_HOME/core/trino-main/src/main/java/io/trino/server/ui/WebUiStaticResource.java:

Add /query/ path. Note any path can be used:

    @GET
    @Path("/query")
    public Response getQuery(@BeanParam ExternalUriInfo externalUriInfo)
    {
        return Response.seeOther(externalUriInfo.absolutePath("/query/")).build();
    }
    
    // asset files are always visible
    @ResourceSecurity(PUBLIC)
    @GET
    @Path("/query/assets/{path: .*}")
    public Response getQueryAssetsFile(@PathParam("path") String path)
            throws IOException
    {
        return getQueryFile("assets/" + path);
    }

    @ResourceSecurity(PUBLIC)
    @GET
    @Path("/query/{path: .*}")
    public Response getQueryFile(@PathParam("path") String path)
            throws IOException
    {
        if (path.isEmpty()) {
            path = "index.html";
        }

        String fullPath = "/query_ui_webapp/" + path;
        if (!isCanonical(fullPath)) {
            return Response.status(NOT_FOUND).build();
        }

        URL resource = getClass().getResource(fullPath);
        if (resource == null) {
            return Response.status(NOT_FOUND).build();
        }

        return Response.ok(resource.openStream()).build();
    }

    private static boolean isCanonical(String fullPath)
    {
        try {
            return new URI(fullPath).normalize().getPath().equals(fullPath);
        }
        catch (URISyntaxException e) {
            return false;
        }
    }

Development

Build and run

1. Install Node.js (v20 or newer) from https://nodejs.org/en/download/
2. Ensure Trino is running at the configured URL. Defaults to http://localhost:8080
3. Install the dependencies and run the dev server:

cd precise
npm install
npm run dev

The local URL is displayed, and you can open it in your browser.

Set up proxying to a local Trino instance

By default vite.config.ts is configured so that queries can be proxied to Trino's query endpoint running on http://localhost:8080. Modify the setting to suit your needs with another URL and updated configuration:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  base: '/query/',
  plugins: [react()],
  server: {
    proxy: {
      '/v1': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        secure: false,
      },
    },
  },
  ...
});

Building the parser

Build the parser, as configured in package.json.

npm run antlr4ng

Linting and code formatting

To check code quality and formatting with ESLint and Prettier, as defined in package.json:

npm run check

Philosophy

This UI's purpose is to provide an environment where, once the cluster is up, you can immediately execute queries and explore data sets. The intended use cases are:

• Initial proof-of-concept queries.
• Exploration of data sets.
• Performance analysis.
• Ad hoc query execution.
• Quickly enabling a data engineering team to start work before other integrations are in place.
• Early demos.

The approach:

1. Direct integration into the Trino UI
   • No need for an additional authentication hop (although it could be added in the future)
   • Authenticates as the user executing the query when using OAuth2
   • Trino does the heavy lifting
2. Remove friction so you can simply write a query
   • Autocomplete understands the Trino language, tables, and columns
   • Provides syntax highlighting and validation
   • Offers a comprehensive catalog explorer
3. Avoid black-box query execution
   • Show progress and execution details. People ask "why is my query slow?" mostly because they only see a spinner for minutes.
   • Link to the Trino Query UI to drill into query performance
   • Show stages and split counts like the Trino console client
4. Keep the experience easy to navigate

Gaps and future direction

• Saving queries and using source control require either backend capabilities in the Trino service or leveraging Trino to write queries as tables.
• No autocomplete for the Trino function list.
• Basic graphing capabilities are still missing—looking at a table alone is not enough even for inspecting data sets.
• No LLM copilot integration yet. Many query UIs implement this poorly, but, done well, it could make query crafting fast and help translate from other query languages.
• Parameters and string replacement are only partly implemented in SubstitutionEditor and should support both SQL parameters and string replacement.