How Computed Tables Work

A Computed Table is a piece of metadata inside Qualytics. Its SQL query lives with the datastore configuration; nothing is written back to the warehouse. This page walks through how the platform resolves that metadata into actual data every time it needs to look at the container.

The Execution Model

A Computed Table is never materialized as a physical warehouse object. When Qualytics needs to look at the container (during a scan, a profile, a quality check run, or a preview), it takes the stored query and runs it against the parent JDBC datastore's connection. The warehouse executes it, returns the rows, and Qualytics treats those rows as the container's live data.

This has three practical consequences you should keep in mind while designing a Computed Table:

• Every scan is fresh. There is no cached copy of the previous run. If the underlying base tables changed, the next scan sees the new data.
• Query cost is real. Complex queries run every time the container is scanned, profiled, or previewed. Aggregations over very large base tables can slow the run down; consider narrowing the query with WHERE, using appropriate indexes on the base tables, or moving heavy preparation into a view or table in the warehouse itself.
• Validation is not execution. The Validate button (see below) confirms the query is syntactically and semantically valid against the warehouse catalog. It does not run the query end-to-end against production data.

Validation

Every Add and Edit modal exposes a Validate button. Clicking it sends the query to the warehouse for parse and semantic checks:

• The SQL must parse in the warehouse's own dialect.
• Every referenced table, view, and column must exist in the warehouse catalog.
• The connection must have permission to select from every referenced object.

If any of those checks fail, the modal surfaces the warehouse's own error message so you can fix the query in place. Running Validate is optional: you can click Save directly, in which case Qualytics validates the query as part of the save request and returns any error inline.

Validation runs synchronously with a default timeout of 150 seconds (configurable per request between 30 and 300 seconds). If the warehouse does not respond in time, the request returns 408 Request Timeout with a message noting the timeout window. Very complex queries against very large base tables can push validation toward that limit.

Query Editor

The Query editor in the Add and Edit modals is a code-aware surface with a few features that speed up writing SQL:

• Syntax highlighting. SQL keywords, identifiers, string literals, and comments are colored.
• Autocomplete. Press Ctrl+Space inside the editor to see a hint list based on the datastore's schema (tables and columns the connection can see).
• Inline hint label. The editor shows a subtle "Any valid query" reminder below the input identifying which dialect applies.
• Fullscreen editor. Click the expand icon in the editor's toolbar to open a larger dialog when the query grows beyond a few lines.

What a Computed Table Can Reference

A Computed Table can only reference base containers in the parent datastore:

The rule exists because Qualytics stores the Computed Table's query as metadata; it does not create a matching view or table in the warehouse. When the warehouse runs the query, it can only find objects that already exist in its own catalog. See Workarounds below for two ways to structure your queries when you would otherwise need to chain Computed Tables.

Connectors That Require Fully-Qualified Names

A few JDBC connectors reject unqualified table names in the SQL body:

• SQL Server: reference tables as SCHEMA.TABLE.
• Oracle: reference tables as SCHEMA.TABLE.
• Redshift: reference tables as SCHEMA.TABLE.

The table picker in the Add / Edit modal shows the schema prefix for these connectors so the identifier you paste into your query already includes the schema. For other connectors, an unqualified name is usually enough as long as the datastore's search path resolves it.

Query Diff

Every save produces a new version of the Computed Table's query. The container's History panel lists these versions as a timeline. Each entry that changed the query exposes a View Query Changes action that opens a From/To dialog highlighting what was added and removed, along with the user and timestamp for that change. This makes it easy to trace when a query changed and to copy a previous version back into the Edit modal if you need to revert.

Basic Profile on Create

When a Computed Table is saved for the first time, Qualytics runs two profiles back to back: a synchronous slim profile that samples up to 1000 records per partition so field-level statistics appear immediately, and a full asynchronous profile in the background using the datastore's default settings. The full profile shows up in the datastore's operations page as it progresses; you can also trigger additional profiles manually whenever you want a fresh run.

Volumetric and Freshness Tracking

Computed Tables support the same volumetric (row-count) and freshness tracking that base tables do. When either is enabled, Qualytics samples the relevant metric on every profile so trend charts populate over time:

• volumetric_tracking_enabled: records the row count on each profile.
• freshness_tracking_enabled: records the newest timestamp on each profile using the container's freshness field.

Two automation toggles turn tracking history into standing anomaly detection:

• automate_volumetric_checks: Qualytics creates a volumetric check that fires on unexpected row-count drops or spikes.
• automate_freshness_checks: Qualytics creates a freshness check that fires when the container's freshness timestamp falls behind its usual cadence.

Enabling automation implicitly enables the corresponding tracking. Submitting automate_volumetric_checks: true while volumetric_tracking_enabled: false turns the tracking flag on for you, and the same cascade applies to freshness.

Editing Triggers a Profile

Saving an edit to a Computed Table's query kicks off validation and re-profiling right away. Qualytics runs a synchronous slim profile so field-level statistics refresh immediately, and follows up with a full asynchronous profile in the background. Existing quality checks are preserved; anomalies raised against the older query text stay in the anomaly history for auditability.

Permissions

Managing a Computed Table follows a hybrid gate on the parent datastore: Editor for the full set of actions, or Author when the caller is (or will be) the owner. Reassigning ownership always requires Editor. Users with the Admin role bypass every team-level check. See Permissions for the full action-by-action matrix (view, validate, create, edit, delete, reassign, profile/scan operations, and quality checks).

Delete Cascades

Deleting a Computed Table is a hard delete. When the delete succeeds, Qualytics removes the container together with its quality checks, anomalies, profile history, and scan history. There is no archive step and no undo.

The delete is blocked with 409 Conflict when quality checks in other containers reference this Computed Table through a configured reference container. The following rule types can trigger the block:

• existsIn
• notExistsIn
• dataDiff
• aggregationComparison
• isReplicaOf (sunsetting; use dataDiff for new checks)

The error response lists the specific quality-check IDs that block the delete. Delete or repoint those checks first, then retry.

Notifications

• Editing a Computed Table sends an in-app notification to the owner, unless the editor is also the owner.
• Creating or deleting a Computed Table does not emit an owner notification.

Team-level or datastore-level notification rules layered on top of this behavior apply as configured elsewhere in the platform.

Workarounds for Referencing Other Computed Tables

Because a Computed Table cannot reference another Computed Table, chained transformation logic has to be expressed inside a single query. Two patterns cover almost every case:

CTEs (Common Table Expressions)

Merge the intermediate steps into one query using WITH ... AS (...):

WITH dataset_a AS (
    SELECT id, name, amount
    FROM source_table_1
    WHERE status = 'active'
),
dataset_b AS (
    SELECT id, category, region
    FROM source_table_2
    WHERE year = 2024
)
SELECT
    a.id,
    a.name,
    a.amount,
    b.category,
    b.region
FROM dataset_a a
JOIN dataset_b b ON a.id = b.id

The whole query executes as a single unit, so the warehouse never has to resolve dataset_a or dataset_b as separate catalog objects.

Materialize the Intermediate as a Warehouse Object

If you need to reuse the intermediate result across multiple Computed Tables, create it as a real view or table in the warehouse itself, catalog it in Qualytics, and reference the cataloged object from your Computed Table queries.

Using Computed Tables in a Computed Join

A Computed Table can be used as an input to a Computed Join as long as it has been profiled at least once. The Computed Join picks up the Computed Table's field schema at the time of the join and treats it like any other container on either side. The only container type a Computed Join refuses is another Computed Join.