Every Value. Every Relationship.
Every Point in Time.

The problem: traditional SQL for time-series

Ask a traditional database for "daily kWh totals per meter for the last 7 days, joined to the customer's region." This is what you get — CTEs, date math, GROUP BY on truncated timestamps, explicit JOINs to a separate customer table. An AI agent must generate all of this correctly, or the query fails.

-- Traditional SQL: 15+ lines, multiple failure points for an LLM
WITH date_range AS (
  SELECT generate_series(
    CURRENT_DATE - INTERVAL '7 days',
    CURRENT_DATE,
    INTERVAL '1 day'
  ) AS day
),
daily_kwh AS (
  SELECT
    m.meter_id,
    DATE_TRUNC('day', r.reading_time) AS day,
    SUM(r.kwh) AS daily_total
  FROM meter_readings r
  JOIN meters m ON r.meter_id = m.id
  WHERE r.reading_time >= CURRENT_DATE - INTERVAL '7 days'
  GROUP BY m.meter_id, DATE_TRUNC('day', r.reading_time)
)
SELECT d.meter_id, d.day, d.daily_total, c.region
FROM daily_kwh d
JOIN meter_customers mc ON d.meter_id = mc.meter_id
  AND mc.effective_date <= d.day
  AND (mc.end_date IS NULL OR mc.end_date > d.day)
JOIN customers c ON mc.customer_id = c.id
ORDER BY d.meter_id, d.day

The same query in GS SQL™ (TEQ™)

The same question. Temporal parameters handle the date range, rollup, and aggregation. The temporal foreign key JOIN resolves which customer each meter belonged to at each point in time — automatically. An AI agent generates this correctly on the first try.

-- GS SQL: 4 lines. Same answer. No date math. No CTEs. No SCD2 joins.
SELECT m.cname, m.kwh(range(sd=-7d), CycleId='daily', Stat='sum'), c.region
FROM meter m
INNER JOIN customer c ON m.customerUid = c.cuid
ORDER BY m.cname

Why this matters for AI

Standard SQL is the #1 source of LLM hallucinations in data applications. Date arithmetic, window functions, CTEs, SCD2 temporal joins — each is a failure point where the model generates plausible but broken syntax. GS SQL eliminates all of them. Temporal parameters (sd, CycleId, Stat, TimeFilterId) collapse complex time-series operations into declarative hints on the column. The platform does the rest.

When an AI agent hears "average temperature last week, rolled up hourly" — it maps directly:

SELECT cname, time, sample(range(sd=-7d), CycleId='hourly', Stat='avg')
FROM STREAM
WHERE id = 'temperature'

No date arithmetic to get wrong. No window functions to hallucinate. No CTEs to nest incorrectly. The query is short enough for an AI agent to generate reliably, and deterministic enough for a human to verify at a glance.

More examples: temporal parameters in action

Peak-hours-only filtering, running totals, lag/lead window operations — all expressed as parameters, not code.

-- Last 30 days, hourly averages, peak hours only
SELECT cname, AVG(sample(range(sd=-30d), CycleId='hourly', Stat='avg', TimeFilterId='peak')) FROM STREAM
WHERE cname LIKE 'Meter%' AND id = 'kwh'
GROUP BY cname

-- Running kWh total for the current month
SELECT cname, kwh(running='sum', range(currentCycle='month')) FROM meter

-- Previous day's temperature (lag window parameter)
SELECT cname, temperature(lag=1, CycleId='daily', range(sd=-30d)) FROM sensor