Examples

Context. An e-commerce team wants Qualytics to monitor customer lifetime value (LTV): for each customer, the total revenue, order count, first and last order dates, and refund exposure. They previously computed LTV in a scheduled warehouse job and had to build a separate observability pipeline on top of it.

What happens. The team writes a single query that joins customers, orders, and refunds, groups by customer, and aggregates. Qualytics stores the definition and every scan runs it against the warehouse. Quality checks land on lifetime_revenue and total_orders; a drop in the aggregate flags a downstream revenue funnel issue directly.

SELECT
    c.customer_id,
    c.email,
    c.acquired_at,
    COUNT(DISTINCT o.id) AS total_orders,
    COALESCE(SUM(o.total), 0) AS lifetime_revenue,
    COALESCE(SUM(r.amount), 0) AS lifetime_refunds,
    MIN(o.placed_at) AS first_order_at,
    MAX(o.placed_at) AS last_order_at
FROM customers c
LEFT JOIN orders o
    ON o.customer_id = c.customer_id
    AND o.status = 'fulfilled'
LEFT JOIN refunds r ON r.order_id = o.id
GROUP BY c.customer_id, c.email, c.acquired_at

Why it works. Aggregations that span multiple base tables and back a business metric belong in a Computed Table when the metric is monitored, not just queried ad hoc. If a base table drops one of the joined columns, the Computed Table's next profile surfaces the loss as a Missing field.

Context. A finance team monitors daily profit-and-loss across every currency the platform transacts in. They want the container to always reflect the current view of the transactions table without maintaining a materialized view themselves, and they want an anomaly the moment a day is missing.

What happens. The Computed Table aggregates by DATE_TRUNC('day', transaction_date) and currency. Every scan re-reads transactions, so the container is always as fresh as the warehouse. With freshness tracking and an automated freshness check enabled, a delayed ingest surfaces the same day.

SELECT
    DATE_TRUNC('day', transaction_date) AS pnl_date,
    currency,
    SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END) AS credits,
    SUM(CASE WHEN amount < 0 THEN amount ELSE 0 END) AS debits,
    SUM(amount) AS net_pnl,
    COUNT(*) AS transaction_count
FROM transactions
GROUP BY DATE_TRUNC('day', transaction_date), currency

Why it works. A rolling metric that gets stale defeats its own purpose. Because a Computed Table is not materialized, every scan re-reads the warehouse; there is no refresh job to forget. With freshness tracking on, a delayed ingest surfaces the same day.

Context. A SaaS product team scores customer engagement weekly by counting users who logged in at least once in the past 7 days, broken down by subscription plan. They want the risk signal (drops in weekly-active users on high-value plans) to fire as a Qualytics anomaly rather than a Slack alert wired by hand.

What happens. The Computed Table uses a CTE to compute the 7-day active user set, then joins to subscriptions and aggregates by plan. Volumetric tracking on the container turns the row count into a monitored series; an automated volumetric check fires on unexpected drops.

WITH active_last_7_days AS (
    SELECT DISTINCT user_id
    FROM user_events
    WHERE event_type = 'login'
      AND event_at >= CURRENT_DATE - INTERVAL '7 days'
)
SELECT
    s.plan_id,
    s.plan_name,
    COUNT(DISTINCT a.user_id) AS weekly_active_users,
    COUNT(DISTINCT s.user_id) AS total_users_on_plan,
    COUNT(DISTINCT a.user_id)::FLOAT
        / NULLIF(COUNT(DISTINCT s.user_id), 0) AS engagement_ratio
FROM subscriptions s
LEFT JOIN active_last_7_days a ON a.user_id = s.user_id
WHERE s.status = 'active'
GROUP BY s.plan_id, s.plan_name

Why it works. CTEs let the container encapsulate multi-step logic without needing a real warehouse view. When the "active" definition changes (say, from 7 days to 14), the Edit flow captures the change in History and re-profiles automatically. The engagement ratio is monitored the same as any other column on the container.

Context. A data-engineering team's raw_orders table contains duplicate rows because the ingest pipeline occasionally replays events. They want to run uniqueness and cross-system reconciliation checks against a clean view, without changing the raw ingest.

What happens. The Computed Table selects one row per order_id using window-function deduplication. Quality checks target the Computed Table, not the raw table. Because a Computed Table is metadata, the raw ingest keeps running as-is; the "clean" projection just exists alongside it.

SELECT
    order_id,
    customer_id,
    status,
    total,
    placed_at
FROM (
    SELECT
        order_id,
        customer_id,
        status,
        total,
        placed_at,
        ROW_NUMBER() OVER (
            PARTITION BY order_id
            ORDER BY placed_at DESC
        ) AS rn
    FROM raw_orders
) t
WHERE t.rn = 1

Why it works. Splitting "raw" and "clean" projections of the same source as two containers keeps monitoring meaningful: the raw table stays observable for pipeline-health checks (duplicate counts, ingest lag), and the clean Computed Table is what business quality checks reference. Anomalies raised against the raw duplicates are traceable back to the source without polluting the clean container's history.