Component reference
RisingWave — streaming threat detection
Engine-anchored architecture for SOCs that cannot afford batch latency. PostgreSQL-compatible streaming database; continuous SQL computation over Kafka and CDC streams; writes natively to Iceberg without a separate buffer layer.
Event-to-rule firing. Replaces the batch-index methodology that creates a five-minute vulnerability window before scheduled queries run. Detection fires the moment an event arrives. Production references: Palo Alto Networks (Cortex XSIAM), China Telecom Bestpay.
The pipeline
-
Sources
Kafka / CDC
Auth logs, API calls, network telemetry, Postgres/MySQL CDC
-
Engine
RisingWave streaming compute
Continuous SQL; incremental view maintenance
-
Store
Iceberg on S3
Exactly-once writes to open table format
-
Serve
SOAR + dashboards
Sub-100ms alerts to automated containment
What composes, what’s brittle
- Production at scale. Palo Alto Networks (Cortex XSIAM), China Telecom Bestpay.
- PostgreSQL-compatible. Standard SQL, no proprietary dialect to learn.
- Native CDC ingestion. Postgres, MySQL, MongoDB streams as first-class inputs.
- Why this matters. Closes the open-format streaming-ingest gap at security scale.
- Materialized views. Ground LLMs and agentic AI on live telemetry, not stale snapshots.
- Best fit. Sub-minute detection that must run on lakehouse-native data.
Sources: RisingWave engineering blog · Palo Alto Networks (Cortex XSIAM) and China Telecom Bestpay public references. Honorable mention: Feldera (incremental view maintenance, conceptually adjacent via DBSP).