Trino Integration

Trino is a distributed SQL query engine, not a data store. Transcend connects to your Trino coordinator over the HTTPS REST API and runs data subject request (DSR) SQL against catalogs Trino can reach — for example Iceberg on object storage, Hive, or operational databases.

Queries are routed through Sombra so credentials stay in your environment. Self-host Sombra for production. The Trino integration requires Sombra 7.516.1 or later.

• Coordinator URL (host and port; default port is 8080) and HTTPS in production.
• Authentication: PASSWORD (username and password) or JWT (pre-issued Bearer token).
• A Trino user with SELECT on tables used for ACCESS, and DELETE (or INSERT and DELETE for MERGE) on tables used for ERASURE.

Trino accepts the connection when authentication succeeds, even if the user has no catalog or table access. A successful connection test does not prove DSRs will return rows.

1. In the Admin Dashboard, go to Infrastructure → Integrations, search for Trino, and add it.
2. Enter the coordinator URL, choose PASSWORD or JWT, and optionally set a default catalog and schema. If you omit those, fully qualify table names in DSR SQL.
3. If the coordinator uses a private CA, paste the CA certificate PEM into the CA Certificate field.
4. Save and run a connection test.

Run a Discovery Scan to recommend datapoints from catalogs, schemas, and tables (built-in catalogs such as system, tpch, tpcds, jmx, and memory are excluded). Content classification is not available yet — after discovery (or if you create datapoints by hand), write ACCESS and ERASURE prepared statements yourself under Manage Datapoints.

Use unquoted placeholders. Prefer @email (named) or {{email}} (template). Do not wrap them in SQL quotes. Quoted '{{email}}' looks up the literal string {{email}}, returns zero rows, and makes erasure look like it never ran. See SQL statement variables for the full variable set.

SELECT first_name, last_name, street, email
FROM iceberg.privacy.customers
WHERE email = @email;

A Delete request does not skip ACCESS. Transcend runs the datapoint’s ACCESS SQL first. If that query returns no rows, ERASURE SQL often never reaches Trino — especially when the integration is set to skip secondary erasure when access found no files. A successful standalone Access request does not prove the ACCESS phase of this Delete request found rows.

If Trino logs show no DELETE, MERGE, or UPDATE for a Delete DSR, inspect the ACCESS prepared statement on the same datapoint. Confirm identifiers are unquoted and that ACCESS returns files for that request ID.

Trino mutations depend on the connector. Iceberg commonly supports DELETE and MERGE INTO; a plain UPDATE can fail even when the same service account can mutate in the Trino CLI. Put redaction or overwrite logic in MERGE INTO (or DELETE) on the ERASURE prepared statement. Review Trino DELETE limitations.

MERGE INTO iceberg.privacy.customers AS t
USING (SELECT @email AS email) AS s
ON t.email = s.email
WHEN MATCHED THEN UPDATE SET
  first_name = 'REDACTED',
  last_name = 'REDACTED',
  street = 'REDACTED';

Each DSR action is one statement. Do not rely on a prior SET session command; ERASURE uses a transaction and session state does not carry across Transcend calls.

A datapoint query is keyed by one identifier type. To AND email with another identifier, combine them in a SQL or custom-function preflight into a single identifier (for example a JSON object), then decompose that value in the Trino SQL.

• Database Integration Set Up for DSR Automation
• Sombra introduction