Time-series analytics at the speed it streams in.

Q: Do streaming materialized views work across ASOF joins too?

Yes — this is the architectural payoff. CREATE MATERIALIZED VIEW … REFRESH ON CHANGE on an ASOF join maintains the join incrementally as new ticks land in the source tables. The heavy lifting runs once; subsequent ticks update the view in place. Agents and dashboards reading the view always see a result that's already current — without re-scanning history on every query.

Time-seriesStreamingGPUASOF

ASOF joins, sliding windows, and inline forecasting on GPU — alongside your vector, graph, and spatial workloads in one engine.

Start FreeTime-series alongside vector · graph · spatial · in one engine

The Category

Time-series lives in three places. Only one sits in your engine.

InfluxDB · TimescaleDB · kdb+ · Prometheus

Purpose-built for ticks. Cut off from everything else.

Dedicated time-series stores handle ingest and bucket aggregations well. They're a separate system. When the question requires joining ticks with customer data, geofences, or vector similarity, you're back to extract-and-move — or you're not asking the question at all.

Fast ingest and downsampling for pure tick streams

Time data is isolated from your operational and analytical tables

Cross-system joins land in app code or a separate ETL layer

The Architecture

Columnar layout, vectorized GPU execution, and continuous materialized-view maintenance — the three things that make time-series fast at scale.

Compute path · streaming time-series query

streaming inputoperatorresult

Columnar layout

Time-series queries usually scan only a few columns. Columnar storage means you read what you need and skip the rest.

Vectorized on GPU

Window aggregates, ASOF, bucketing — all execute as vectorized kernels on GPU. Per-row work parallelizes across thousands of cores.

Continuous maintenance

Materialized views refresh on change as new ticks arrive — your aggregates stay fresh without re-scanning history.

The Numbers

3× faster than SingleStore. 2.5× faster than ClickHouse.

Query throughput · more is better

3× SingleStore on QPS

Flex JMeter, Phase 2 hardware, identical workload

Kinetica107 QPS

ClickHouse43 QPS

SingleStore36 QPS

Concurrent query + ingest · more is better

4× ClickHouse under load

QPS while ingesting 400k rec/sec simultaneously

Kinetica97 QPS

ClickHouse24 QPS

SingleStore19 QPS

Sustained ingest · more is better

2× on data loading

Records per second sustained, GPU + CPU

Kinetica600k/s

ClickHouse300k/s

SingleStore300k/s

Scale stability · 2B → 8B records

~6%

Max degradation from 2B to 8B records

100+

Sustained QPS at every scale point

0.00%

Error rate across all tests

Source: Tier-1 bank proof of concept · Phase 1 (Kinetica Lab, US, R620/T4) · Phase 2 (Dell Lab, Ireland, R760XA/L40s) · 2025. Numbers shown as published; benchmark refresh in progress.

The Toolkit

The full temporal toolkit, in standard SQL.

Window functions

OVER · PARTITION BY · sliding

Aggregate, rank, and offset over rows ordered by time. RANGE or ROWS framed.

SELECT ts, price,
       AVG(price) OVER (
         PARTITION BY symbol
         ORDER BY ts
         RANGE INTERVAL '5' MIN
           PRECEDING
       ) AS ma5
  FROM ticks;

AVG · SUM · MIN · MAX · LAG · LEAD

FIRST_VALUE · LAST_VALUE · NTILE

ROW_NUMBER · RANK · DENSE_RANK · CUME_DIST

Time bucketing

TIME_BUCKET · DATE_BUCKET

Snap irregular timestamps to fixed intervals. Aligned buckets you can group by.

SELECT
  TIME_BUCKET(
    INTERVAL '1' MIN, ts
  ) AS bucket,
  SUM(volume) AS vol
FROM ticks
GROUP BY bucket;

TIME_BUCKET · DATE_BUCKET

DATE_TRUNC · interval arithmetic

GAP-FILL · LATEST_BY

Trend & forecast

PREDICT · OUTLIERS

Forecasting and anomaly detection inline in SQL. No separate ML pipeline.

SELECT *
  FROM PREDICT(
    SELECT ts, price
      FROM ticks
  )
  FORECAST
  FOR INTERVAL '10'
    MINUTE;

PREDICT · forecast horizons

OUTLIERS · anomaly detection

REGRESSION · trend functions

The Killer Operator

ASOF join connects two time-series when timestamps don't align — for every row, at GPU speed, in standard SQL.

ASOF Join · trades against quotes within 1ms tolerance

tradesquotesmatched within tolerance

SQLASOF Join

-- for each trade, find the most recent
-- quote within 1ms tolerance after
SELECT *
  FROM trades t
  LEFT JOIN quotes q
    ON t.symbol = q.symbol
   AND ASOF(
         t.ts, q.ts,
         INTERVAL '0' SECOND,
         INTERVAL '1' MILLISECOND,
         MIN
       );

define both window bounds + MIN/MAX selector

The result: for every trade, the closest matching quote within the configured window. Trades with no qualifying quote return NULL (LEFT JOIN). The whole thing runs vectorized on GPU, in a single SQL statement.

Customer · Mahindra Formula E Racing

“Kinetica's unique ASOF join capability — correlating different car sensor readings with offset timestamps across 8,000 tables of individual sensor time-series — set it apart from competitors and secured the deal.”

Cameron Maultby · Chief Commercial Officer, Mahindra Racing

The Streaming Mode

Materialized views refresh on change as ticks arrive, including across ASOF joins. The expensive computation runs once.

Streaming materialized view · ASOF join · refresh on change

incoming ticksview kept freshagent / dashboard query

SQLREFRESH ON CHANGE

-- ASOF join, kept fresh as
-- new ticks arrive — automatically
CREATE OR REPLACE
  MATERIALIZED VIEW trades_q
  REFRESH ON CHANGE
AS (
  SELECT *
    FROM trades t
    LEFT JOIN quotes q
      ON ASOF(
           t.ts, q.ts,
           INTERVAL '0' SEC,
           INTERVAL '1' MS,
           MIN
         )
);

heavy lifting, once · stays current

Why this mattersMost databases force you to choose: pre-compute the join (stale) or re-run on every query (slow). Kinetica's lockless engine maintains the join incrementally as new ticks arrive — your dashboard reads a result that's already current.

Engineering note

ASOF JOIN is where engines that "support time-series" usually fall apart. A naive plan does a cross-join and filters — quadratic on row count, fine for a million ticks, fatal at a billion. The right plan walks both series in sorted order with a moving pointer; each tick on the left finds its match in O(1), not O(log n) and definitely not O(n). Sorted column storage and partition-aligned shards are what make that pointer walk possible without a global sort.

— Kinetica engineering · 8.4B trade ticks ASOF-joined to 2.1B quote ticks across 12 months · 4.2 sec on a 4-node cluster · same join modeled as a Postgres window function w/ LATERAL: did not complete after 6 hours

Time-series operations built for the workloads that already broke your last database.

Start Free Read the docs

Frequently asked questions

What makes time-series workloads harder than other analytical workloads?

Three things compound: high-cardinality timestamps that defeat B-tree indexing, moving-window aggregates that re-scan overlapping ranges and grow quadratically on CPU, and joins across streams whose timestamps never line up exactly. Each is expensive on its own — together they're brutal on a row-store database. Kinetica's columnar layout, GPU-vectorized window kernels, and native ASOF operator address all three in a single engine.

What is an ASOF join, and why is it considered the "killer operator" for time-series?

ASOF finds the closest matching row in another table within a tolerance window you define — when there's no equality match between timestamps. Classic example: for each trade, find the most recent quote within 1ms. Kinetica's ASOF goes further than most implementations: you can define both ends of the lookback window plus a MIN/MAX selector for picking among candidates inside it. The whole operator runs vectorized on GPU in a single SQL statement — no app-side workaround required.

How does Kinetica compare to ClickHouse and SingleStore on time-series benchmarks?

In a Tier-1 bank proof of concept on identical hardware against 8 billion records, Kinetica delivered roughly 3× SingleStore on raw QPS, 2.5× ClickHouse on QPS, and 4× ClickHouse under concurrent query + ingest. Sustained ingest came in at 600k rec/sec versus 300k for both ClickHouse and SingleStore. Across scale points from 2B to 8B records, Kinetica held 99–106 QPS — about 6% max degradation, 0.00% error rate.

Can I use standard SQL for window functions, time bucketing, and forecasting?

Yes. AVG / SUM / LAG / LEAD / FIRST_VALUE / LAST_VALUE / RANK / NTILE / CUME_DIST work in standard ANSI SQL OVER clauses with RANGE or ROWS framing. TIME_BUCKET and DATE_BUCKET snap irregular timestamps to fixed intervals. PREDICT runs inline forecasting in the same SQL pipeline — no separate ML service to operate. Postgres-wireline compatibility means your existing tools, your team's skills, and your LLMs all work the day you start.

Do streaming materialized views work across ASOF joins too?

Yes — this is the architectural payoff. CREATE MATERIALIZED VIEW … REFRESH ON CHANGE on an ASOF join maintains the join incrementally as new ticks land in the source tables. The heavy lifting runs once; subsequent ticks update the view in place. Agents and dashboards reading the view always see a result that's already current — without re-scanning history on every query.

Does time-series share an engine with vector, graph, and geospatial — or is it a separate product?

Single engine. The same columnar storage, the same GPU-vectorized executor, and the same SQL surface run time-series, vector search, graph analytics, and geospatial workloads side-by-side. There's no separate "time-series database" to operate alongside your analytical store — joins across capabilities are just SQL joins.