Data your agents can query the moment it lands.

Q: How do streaming materialized views stay fresh without re-running the whole query?

When you CREATE MATERIALIZED VIEW … REFRESH ON CHANGE , the engine plans an incremental maintenance step that fires as new rows arrive in the source tables. Joins, aggregations, and windowed calculations are updated in place — the view never re-scans from scratch. Agents and dashboards reading the view always see a result that's already up to date.

Q: What streaming sources and sinks does Kinetica connect to natively?

Native subscribers for Kafka (and Confluent), Kinesis , and Pulsar read directly into Kinetica tables. Object stores like S3 and Azure Blob , plus any JDBC -compatible source, are supported as both sources and sinks. CREATE STREAM defines push triggers that fan out matched rows to Kafka topics, webhooks, or downstream databases — no polling, no central event bus.

Real-timeAnalyticalDistributedSQL

Writes don't wait for reads. Ingest and query run against the same data simultaneously, with no locking and no batch window.

Start FreeAvailable on cloud · on-prem · edge

The Mechanism

Client-side sharding sends writes directly to the owning worker — no coordinator, no bottleneck.

Multi-head ingest · data routing map

routing mapdata pathbypassed

Routing

Client computes target rank + TOM per record using cached shard map.

Parallelism

N workers ingest simultaneously. No coordinator queue, no leader bottleneck.

Linear scale

Add worker ranks → ingest throughput scales with them. No coordinator to outgrow.

The Payoff

Reads and writes run concurrently on the same partition. No replicas, no stale data, no waiting.

Traditional database

Writes lock the table — queries wait

Kinetica

Lockless — reads and writes run together

The Trick

Materialized views refresh incrementally as rows land. Complex joins and aggregations stay current — without re-scanning history.

Streaming materialized view · incrementally maintained

incoming rowsview kept freshagent query

SQLCREATE MATERIALIZED VIEW

-- aggregates kept fresh as rows land
CREATE MATERIALIZED VIEW
  streaming_demand
  REFRESH ON CHANGE
AS SELECT
  station_id,
  AVG(num_available)
    OVER (
      PARTITION BY station_id
      ORDER BY ts
      RANGE INTERVAL '5' MINUTE
        PRECEDING
    ) AS avg_5min
FROM station_status;

windowed aggregation · maintained incrementally

Materialized views

Declare what should stay fresh in SQL. The engine handles incremental updates as rows arrive.

Window functions

Tumbling, sliding, and time-bounded windows in standard ANSI SQL OVER clauses.

Standard SQL

Joins, CTEs, JSON, geospatial. Postgres-wireline compatible — your tools just work.

Sources & sinks

Connect to whatever's already streaming.

Native Kafka subscription, Kinesis, Pulsar, S3, Azure Blob, JDBC sources — Kinetica reads from and writes back to the systems your agents already touch.

Kafka

stream · native

Confluent

stream

Kinesis

stream

Pulsar

stream

Spark

batch · stream

object

Azure Blob

object

JDBC

database

The Query

Multi-table joins, windowed aggregations, complex filters — on data still arriving. In milliseconds.

Complex query · streaming + reference data · single statement

streamingreferenceresult

The question being asked

“Which Citi Bike stations are running low on bikes right now, given current weather and the rolling 5-minute demand for each station?”

3-way joinWindow functionStreaming + referenceVectorized executionPostgres-wirelineSingle SQL statement

The Egress

Results fan out from every worker in parallel — no head-node collation, same parallelism as ingest.

Distributed egress · pull and push

agent pullstream push

Pull

Agent issues a query, all ranks return their share.

Query fans out to every worker that owns relevant data. Each rank computes its share in parallel and streams partial results back directly to the agent — no head-node collation.

-- agent issues a query · all ranks respond
SELECT station_id, avg_5min
  FROM streaming_demand
  WHERE avg_5min &lt; 5;

Push

Matched rows stream out to sinks the moment they're written.

Define a streaming trigger in SQL. When a row matches the predicate on any rank, that rank pushes the event directly to a Kafka topic, webhook, or downstream system — no polling, no central event bus.

-- triggers fire from any rank · in parallel
CREATE STREAM low_supply
  ON TABLE streaming_demand
  WHERE avg_5min &lt; 5
  WITH OPTIONS (sink = 'kafka');

SymmetryJust like ingest doesn't route through the head node, egress doesn't either. Every worker rank is a first-class read endpoint and a first-class push endpoint. The parallelism story holds end to end.

Engineering note

Most engines treat ingest and query as competing for the same memory pages, so one blocks the other under load. MVCC snapshots let readers see a consistent view while writers append in parallel — the writer never waits for the reader, the reader never waits for the writer. Throughput stays flat as concurrency climbs, instead of cliff-edging at the lock contention threshold.

— Kinetica engineering · sustained 1.2M events/sec ingest with 40 concurrent dashboards querying the same tables · p99 query latency 180ms steady · same workload on a row-store w/ row-level locks: ingest collapsed to 90K/sec under read load

Build agents on data that moves at their speed.

Start Free Read the architecture deep-dive

Frequently asked questions

How does multi-head ingest avoid the leader-node bottleneck other distributed databases hit?

Most distributed databases route every write through a single leader rank, which becomes a bottleneck under streaming load. Kinetica's client fetches the shard map once, caches it, and from then on computes the target worker rank for every record locally. Writes go directly from the client to the worker that owns the shard — in parallel, with no central choke point. Throughput scales linearly as you add worker ranks.

What does "lockless concurrent reads and writes" actually mean?

Traditional databases acquire a write lock on a table or partition while writes are in flight, which forces concurrent queries to wait — or to read stale data from a replica. Kinetica's storage engine was designed lockless: writes append into the same partition that reads are scanning, with versioned visibility. Newly written rows are queryable the moment they land — no batch window, no replica lag.

How do streaming materialized views stay fresh without re-running the whole query?

When you CREATE MATERIALIZED VIEW … REFRESH ON CHANGE, the engine plans an incremental maintenance step that fires as new rows arrive in the source tables. Joins, aggregations, and windowed calculations are updated in place — the view never re-scans from scratch. Agents and dashboards reading the view always see a result that's already up to date.

What's the realistic end-to-end latency for a complex query against streaming data?

For typical analytical workloads — a 3-way join across two streaming tables and a reference table, with a windowed aggregation and a filter — Kinetica returns results in roughly 100–250ms end-to-end on representative hardware. Latency depends on cardinality, shard layout, and concurrent load, but the architecture (vectorized execution, GPU+CPU parallelism, no head-node collation) is designed to keep the p99 close to the p50.

What streaming sources and sinks does Kinetica connect to natively?

Native subscribers for Kafka (and Confluent), Kinesis, and Pulsar read directly into Kinetica tables. Object stores like S3 and Azure Blob, plus any JDBC-compatible source, are supported as both sources and sinks. CREATE STREAM defines push triggers that fan out matched rows to Kafka topics, webhooks, or downstream databases — no polling, no central event bus.