.svg)
.png)
Trino's power is also its observability blind spot. As a distributed SQL query engine designed to federate queries across heterogeneous data sources — data lakes, warehouses, object storage — it sits across the top of your data infrastructure rather than inside any single layer of it. That architectural position makes it exceptionally fast and flexible for querying. It also makes it exceptionally hard to observe.
This isn't an infrastructure observability problem — Trino has reasonable tooling for query performance and resource monitoring. The gap is data observability: whether the data being queried through Trino is reliable, fresh, structurally consistent, and quality-validated.
When something goes wrong in a Trino-powered environment, the typical experience is fragmented: query performance degrades with no clear root cause, schema changes in an underlying catalog silently break dependent workloads, data quality issues go undetected because there's no systematic monitoring layer, and freshness assumptions built into downstream pipelines have no mechanism for validation. Standard observability tooling that operates at the storage or pipeline layer doesn't reach Trino cleanly. The result is a gap — often a large one — between what teams assume about their data and what's actually true.
The core problems are consistent across organizations running Trino at scale:
- No unified metadata visibility. Trino federates across catalogs, but there's no single place to inventory what's there, track schema state, or understand what changed and when.
- Schema drift goes undetected. Column additions, removals, and type changes in underlying catalogs propagate silently into Trino workloads. By the time a pipeline or report breaks, the change has been in place for hours or days.
- Data quality is assumed, not measured. Without profiling and anomaly detection running against Trino-managed datasets, teams are operating on trust rather than evidence — particularly risky in environments where Trino is used for business-critical reporting or ML feature pipelines.
- Freshness and reconciliation are manual. Validating that data is current and consistent across sources requires custom scripting and periodic spot checks. There's no automated, policy-driven mechanism to enforce SLAs.
- Incident response lacks context. When a Trino query fails or returns unexpected results, there's no observability baseline to compare against — no historical profile, no drift history, no quality trend — making root cause analysis slow and largely intuitive.
ADOC 26.3.0 closes this gap with the General Availability of Trino as a fully integrated data source, delivering automated crawling, profiling, anomaly detection, schema drift monitoring, reconciliation, and freshness tracking — all within the same observability framework applied to the rest of your data stack.
What's Now GA
Metadata Crawling and Catalog Indexing
ADOC crawls Trino catalogs automatically, indexing metadata across tables and schemas to give data teams a current, searchable inventory of their Trino-managed assets. Catalog scope is configurable at setup — teams can target specific catalogs rather than scanning the entire Trino environment — and crawler execution can be scheduled on a recurring cadence to keep metadata current without manual intervention.
Data Profiling
Full profiling is supported across all connector configurations, covering column-level statistical analysis including null rates, cardinality, value distributions, and data type consistency. Profiling runs establish the baseline needed for anomaly detection and give data teams the factual foundation to answer questions about data shape and health that were previously left to guesswork.
Anomaly Detection and Data Quality Monitoring
Configurable anomaly detection with threshold policies is available across the majority of connector configurations, enabling automated identification of statistical deviations from established baselines. When values fall outside expected ranges or distributions shift unexpectedly, ADOC surfaces the issue before it reaches downstream consumers.
Schema Drift Monitoring
Schema drift detection is available across all connector configurations and can be enabled during observability setup. ADOC compares schema state across crawl cycles and flags unexpected changes — column additions, removals, type changes — so teams are notified of structural shifts rather than discovering them through broken queries or failed jobs.
Reconciliation
Data equality checks and native SQL filter-based reconciliation are supported across AVRO, Spark catalog, Pushdown, and SQL View configurations. This enables automated validation that data is consistent across sources — a capability that previously required custom scripting to approximate.
Contrasting the two approaches to Trino Data Observability
Not all Trino data observability integrations are equal. A common approach in the market infers data health by reading query logs — useful for building lineage graphs from historical query patterns, but limited in what it can actually tell you about the data itself. Acceldata Data Observability Cloud (ADOC) takes a different approach: active crawling and direct profiling of the data assets Trino sits on top of.
| Log-Based Inference | Native Integration by Acceldata ADOC |
|
|---|---|---|
| How it works | Queries will be discovered through the openlineage config as pipeline | Actively crawls catalogs and directly profiles data assets |
| Data quality visibility | Derived from query behavior — no direct measurement of data values | Direct profiling of column distributions, null rates, anomalies, and schema state |
| Schema drift detection | Detects changes only when a query runs against the changed schema | Detects drift proactively across crawl cycles, independent of query activity |
| Freshness & reconciliation | Limited to what query logs reveal about when data was last accessed | Policy-driven freshness monitoring and data equality checks across sources |
Connector and Execution Engine Support
ADOC supports two execution engine options for Trino workloads:
- Spark — recommended for large-scale processing and profiling workloads, and required for Freshness and Cadence monitoring
- Pushdown — executes queries directly in Trino for lower-latency operations in performance-sensitive environments
Both engines support SQL View variants for environments using virtual table definitions as observation targets. The full capability matrix across connector configurations is available in the ADOC documentation.
Key constraints to be aware of:
- Cadence and Freshness monitoring are not available for Pushdown and SQL View connector configurations
- Reconciliation is not supported for the Spark JSON connector
- Trino Serverless is not supported in this release
- SSL must be enabled on the Trino server — non-SSL connections are not accepted
Getting Started
Trino connects to ADOC via JDBC using username/password authentication, with optional AWS Secrets Manager integration for secure credential storage. After connecting and triggering an initial crawl, teams can configure profiling, drift monitoring, reconciliation policies, and alerting directly from the Data Sources page.
Full setup documentation, including connector configuration guidance and the complete capability support matrix, is available in the ADOC docs.
.webp)
.webp)
