Decube Data Observability

Decube data testing

Decube checks SQL tables with rule-based tests and shows the rows that fail. It has no table comparison or data diff.

• SQL Table Tests: Field Health monitors cover null %, uniqueness, value ranges, regex/email/UUID format validation; Custom SQL monitors execute any SQL logic; Schema Drift monitors check structural consistency; Freshness monitors validate timestamp-based ingestion windows (docs).

• Inspect Failed Rows: The Preview tab on the Incident Details page shows a data preview of the affected table or column at the time the incident was detected (docs).

• DataFrame Tests: Decube is a SQL-against-warehouse tool with no support for Python DataFrame libraries such as Pandas, Spark, Polars, or Great Expectations (docs).

• Unstructured Data Tests: No LLM-based validation of free-text or JSON columns found in documentation; Trusty AI is metadata-only and cannot execute raw data queries (docs).

• Table Comparison Tests: No dedicated feature for aggregate-level consistency checks between two tables (e.g., row count or sum reconciliation between source and destination) was found (docs).

• Data Diff: No row-by-row or value-by-value comparison tool between two datasets to surface individual differing records was found in documentation (docs).

• Data Contracts: The website mentions 'Data Contracts' under the Data Products section for producer-consumer trust, but no distinct machine-readable YAML/JSON schema + quality SLA contract system is documented (website).

Decube data observability

Decube profiles columns, and Smart Training builds an ML confidence interval from past scans to flag anomalies. Monitors are configured in the UI.

Compare: data observability tools · data profiling tools

• Data Profiling: The Profiler module computes null %, unique %, min, max, mean, median, stddev, and value distributions per column with historical snapshots (docs).

• Anomaly Detection: Smart Training builds an ML confidence interval from historical scan data; alerts fire when a new scan falls outside the interval without requiring hardcoded thresholds (docs).

• Freshness Monitors: Freshness monitors use an ML model trained on historical arrival patterns to detect when data stops arriving on its expected schedule (docs).

• Volume Monitors: Volume monitors track the row-count increment per scan window using ML-derived expected ranges and open incidents on unexpected spikes or drops (docs).

• Schema Monitors: Schema Drift monitors are auto-created on all tables at connection time and detect column additions, deletions, data type changes, and other structural modifications (docs).

• Field Monitors: Field Health monitors track column-level metrics (null rate, unique rate, average, min, max, cardinality, string length) as time series with anomaly detection (docs).

• Segment Monitors: Grouped-By monitors split any monitor type by a dimension column, creating one independent sub-monitor per distinct value for per-segment visibility (docs).

• Custom SQL Monitors: Custom SQL monitors let users write any SQL query; Decube counts failing rows and opens an incident when the count exceeds zero (docs).

• Window-Based Monitors: Monitors can be scheduled at intervals as frequent as every 1 hour, enabling intra-day tumbling window evaluation (docs).

• UI-Based Monitors: All monitor types are created and configured entirely through a no-code GUI; setup guides describe UI-only workflows (docs).

• Monitors-as-Code: No YAML/Python/SQL code-first monitor definition or CI/CD deployment mechanism was found; the Export/Import feature covers only CSV-based metadata updates, not monitor deployment (docs).

• Distribution Monitors: Cardinality (distinct value count) is tracked over a rolling window, but explicit histogram or percentile drift monitoring was not found in documentation (docs).

• Partition-Based Monitors: The Profiler supports date/time filter configuration for scans, but a dedicated partition-based monitoring option (scan only a specific date partition) for ongoing monitors was not explicitly documented (docs).

• Pipeline Monitoring: Job Failure monitors detect ETL pipeline failures for dbt and Airflow, but explicit tracking of job durations and run-time statistics was not documented (docs).

Decube incident management

Decube triages incidents, takes feedback on alerts and opens tickets.

• Alert Notifications: Decube supports alert notifications via email, Slack channels, and Microsoft Teams (docs).

• Incident Triage: Incidents can be assigned to team members directly from the Incident Details page; audit history logs all assignments and status changes (docs).

• Alert Feedback: Users can mark incidents as accurate or false positive via thumbs up/down; clicking thumbs down on a Smart Training monitor reveals a sensitivity slider (–5 to +5) to adjust the confidence interval (docs).

• Incident Resolution: Incidents can be closed once resolved or muted for a set period; audit history records the resolution with a 'via bulk action' label for bulk updates (docs).

• Ticketing Integrations: Jira is listed as a Ticketing and Collaboration integration in the sidebar navigation (docs).

• On-Call Integrations: No PagerDuty, Opsgenie, or VictorOps on-call paging integrations were found in documentation; only Slack, Teams, email, and webhooks are documented (docs).

Decube data quality analytics

Decube's dashboards, health scores and resolution metrics track data quality.

• Data Quality Dashboards: A dedicated Quality dashboard shows DQ scores by dimension (accuracy, completeness, uniqueness, validity, timeliness), with trend charts, source/domain summaries, and filter controls (docs).

• Data Health Scores: Per-table Data Quality Scorecards compute a health score using the formula 1 − (ErrorRows / TotalRows), color-coded green/yellow/red with dimension-level breakdowns (docs).

• Incident Resolution Metrics: Decube's Data Quality dashboard includes an incidents analytics view tracking "average time to close incidents" across timeframes plus incident status breakdowns (open/muted/closed) by level and type (docs).

Decube data lineage

Decube generates lineage from metadata and query history at table and column level, end to end, with impact analysis.

Compare: data lineage tools

• Table-Level Lineage: Automated lineage generates table-to-table flow graphs from query logs and transformation manifests (dbt, Fivetran, Airflow, OpenLineage) (docs).

• Column-Level Lineage: Column-level lineage traces field-to-field dependencies via SQL SELECT parsing, allowing users to select a column on any node to filter the lineage graph (docs).

• End-to-End Lineage: Lineage spans from data lakes (S3, ADLS, GCS) and databases through transformation tools (dbt, Fivetran, Airflow) to BI tools (Tableau, Looker, PowerBI) (docs).

• Impact Analysis: The Impacted Areas tab on the Incident Details page lists all downstream tables, jobs, and dashboards affected by an incident based on lineage; exportable as CSV (docs).

Decube data governance

Decube's catalog and data products show open incidents and owners per asset.

Compare: data catalog tools

• Data Catalog: A full built-in Assets Catalog provides searchable asset inventory with descriptions, tags, classifications, ownership assignment, and lineage integration (docs).

• Data Products: Decube launched a dedicated "Data Products" feature (replacing an earlier Data Mesh/Domains module) that lets producers package trusted assets into curated, discoverable data products with a marketplace-style browsing experience (docs).

• Data Catalog Integration: Decube is itself a data catalog; no documentation was found for pushing quality scores into external catalogs such as Atlan, Alation, Collibra, or Databricks Unity Catalog (docs).

• Data Classification: Auto-classification policy rules match keywords or Elasticsearch regex against asset and column names and apply masking types in Preview; the docs describe no scanning of column values, which this row requires alongside name matching (docs).

Decube workflows

Decube has a REST API, webhooks, scheduling and a dbt integration. It has no Python SDK.

• Scheduling: Monitors run on configurable intervals: every 1h, 3h, 6h, 12h, daily, weekly, or monthly with timezone and time-of-day settings (docs).

• Webhooks: Decube supports a webhooks integration that sends incident alert payloads to a user-configured URL endpoint (docs).

• REST / GraphQL API: A Public REST API (currently in BETA) is available with API key authentication, supporting catalog, glossary, lineage, and user management endpoints (docs).

• dbt Integration: Both dbt Cloud and dbt Core are supported; Decube ingests metadata from dbt models, surfaces Job Failure monitors, and maps lineage to/from upstream and downstream connectors (docs).

• MCP Server: No Model Context Protocol server for AI coding agents was found in documentation or on the website (docs).

• Python SDK: No pip-installable Python client or SDK was found; programmatic access is available only via the REST API (docs).

• CI/CD Integrations: CI/CD pipeline integration has not been confirmed; no feature for actively blocking PR merges or pipeline deployments on quality failures was found in documentation (docs).

Decube AI agents

Decube writes tests from plain-language prompts and suggests tests automatically. It has no AI chat, AI triage or MCP server.

• Natural Language Test Generation: Trusty AI / the MCP interface lets users request monitors in plain English (e.g., "Recommend me monitors for the Snowflake source. Create the monitors once I've approved them") and creates them after approval; leans on profiling-based recommendations rather than fully custom user-authored logic (docs).

• Automated Test Generation: Trusty AI reads column-level profiling statistics and provides recommendations for which monitors to set up based on profiling signals, without requiring user input (docs).

• AI Chat Assistant: Decube has no in-product AI chat assistant; Trusty AI is a read-only metadata assistant rather than a conversational interface for querying or creating monitors (docs).

• AI Issue Triaging: No AI-based incident classification, grouping, or root cause surfacing was found; incident triage is manual (docs).

• AI Issue Resolution: No AI-proposed or automated remediation (SQL fix, pipeline rerun, quarantine) was found in documentation (docs).