Microsoft Fabric Real-Time Intelligence: Eventhouse, KQL, and Streaming Analytics Without the Infrastructure

Fabric Real-Time Intelligence went GA with a clear promise: run a full streaming analytics pipeline — ingestion, storage, query, and alerting — without managing Kafka, Flink, or dedicated Kusto clusters. Eventhouses store billions of events with KQL query performance, CDC replication support, and native integration with Fabric Lakehouses for historical analysis.

The question is not whether it works. It does. The question is when to use it versus the alternatives you may already have.

What Fabric Real-Time Intelligence Actually Is

┌─────────────────────────────────────────────────┐
│         Fabric Real-Time Intelligence            │
│                                                   │
│  ┌────────────┐    ┌──────────────────────┐      │
│  │  Eventhouse │───▶│  KQL Database         │      │
│  │  (storage)  │    │  (query engine)       │      │
│  └────────────┘    └──────────────────────┘      │
│       │                    │                      │
│       │                    ▼                      │
│       │            ┌──────────────────────┐      │
│       │            │  KQL Queries          │      │
│       │            │  (real-time dashboards)│     │
│       │            └──────────────────────┘      │
│       │                                           │
│       ▼                                           │
│  ┌────────────────────────────────────────┐      │
│  │  Activator (alerting & automation)      │      │
│  │  → Trigger Power Automate               │      │
│  │  → Send Teams/Email alerts              │      │
│  │  → Execute Logic Apps                   │      │
│  └────────────────────────────────────────┘      │
│                                                   │
│  ┌────────────────────────────────────────┐      │
│  │  Fabric Lakehouse (historical)          │      │
│  │  ← CDC replication from Eventhouse     │      │
│  └────────────────────────────────────────┘      │
└─────────────────────────────────────────────────┘

Eventhouse is the storage and compute engine. It stores events in a columnar format optimized for time-series queries. Think of it as Azure Data Explorer (Kusto) integrated into Fabric.

KQL Database provides the query language. Kusto Query Language is purpose-built for log analytics, telemetry, and time-series data. It is faster than SQL for these workloads because it is designed for them.

Activator is the alerting layer. It monitors query results and triggers actions when conditions are met — no custom polling code required.

Lakehouse Integration means Eventhouse data can be replicated to a Fabric Lakehouse for historical analysis, combining real-time and batch data in one platform.

When to Use Fabric Real-Time Intelligence

Use Fabric RTI when:

  • You are already on Fabric. The integration with Lakehouse, Power BI, and the rest of the Fabric ecosystem is the primary value. No ETL between streaming and batch layers.
  • You need real-time dashboards on operational data. KQL queries on Eventhouse return in milliseconds for billions of rows. Power BI DirectQuery on KQL makes this instant.
  • You want managed alerting without building infrastructure. Activator handles threshold monitoring, anomaly detection, and automated response without custom code.
  • Your data is already in KQL or can be ingested via standard connectors. Eventhouse supports Event Hubs, IoT Hub, OPC UA, and REST API ingestion.

Do NOT use Fabric RTI when:

  • You need complex event processing (CEP). Eventhouse stores and queries events but does not implement stream processing topologies (windowing, joins across streams, stateful processing). Use Azure Stream Analytics or Flink for that.
  • You need exactly-once processing guarantees. Eventhouse provides at-least-once delivery. For financial transactions requiring exactly-once semantics, use Event Hubs + custom processing.
  • You need multi-region write. Eventhouse is single-region. For globally distributed streaming, use Cosmos DB or Event Hubs with Geo-DR.

Fabric RTI vs Azure Data Explorer vs Event Hubs + Stream Analytics

Criteria Fabric RTI Azure Data Explorer Event Hubs + Stream Analytics
Infrastructure management None (Fabric-managed) Cluster provisioning Multiple services
Query language KQL KQL SQL-like (Stream Analytics)
Storage model Eventhouse (columnar) ADX tables Custom (you manage)
Cost model Fabric CU-based ADX compute units EH throughput + SA streaming units
Integration Fabric native Standalone + Kusto Query Azure-native
Real-time dashboards Power BI native Power BI + ADX connector Power BI + custom
Alerting Activator (built-in) Custom logic apps Built-in alerts
CDC support GA (April 2026) Supported Custom
Best for Fabric shops Independent streaming analytics Complex event processing

My decision rule:

def choose_streaming_platform(
    on_fabric: bool,
    needs_cep: bool,
    needs_exactly_once: bool,
    budget_conscious: bool
) -> str:
    """Select the streaming analytics platform."""

    if needs_cep:
        return "Event Hubs + Stream Analytics"

    if needs_exactly_once:
        return "Event Hubs + Custom Processing"

    if on_fabric:
        return "Fabric Real-Time Intelligence"

    if budget_conscious:
        return "Azure Data Explorer"

    return "Fabric Real-Time Intelligence"

KQL Query Patterns

Here are the most common KQL patterns for production workloads:

// Time-series aggregation: requests per minute over last hour
requests
| where timestamp > ago(1h)
| summarize request_count = count() by bin(timestamp, 1m), status_code
| render timechart

// Anomaly detection: find unusual error spikes
requests
| where timestamp > ago(24h)
| where status_code >= 500
| summarize error_count = count() by bin(timestamp, 5m)
| extend anomalies = series_decompose_anomalies(error_count, 1.5, -1, 'linefit')
| where arraylength(anomalies) > 0

// CDC replication: track changes in source database
changes
| where source_table == "customer_orders"
| where operation == "insert" or operation == "update"
| project timestamp, operation, primary_key, changed_column, new_value

// Top-N with percentile: slowest endpoints
requests
| where timestamp > ago(1h)
| summarize 
    avg_duration = avg(duration_ms),
    p95_duration = percentile(duration_ms, 95),
    request_count = count()
    by endpoint
| top 10 by p95_duration desc

Activator Alerting Patterns

// Alert: Error rate exceeds 5% in any 5-minute window
requests
| where timestamp > ago(5m)
| summarize 
    total = count(),
    errors = countif(status_code >= 500)
| extend error_rate = errors * 100.0 / total
| where error_rate > 5.0

Configure Activator to: 1. Monitor this query every 5 minutes 2. When results are non-empty (threshold exceeded): - Send Teams alert to #ops-alerts channel - Create incident in ServiceNow - Execute runbook to scale up compute

This replaces custom polling, monitoring dashboards, and alert scripts.

Cost Modeling

Fabric Real-Time Intelligence costs are based on Fabric Capacity Units (CUs):

Workload Estimated CU/Hour Monthly Cost (RM)
Light ingestion (1K events/sec) 2-4 CU ~RM 800-1,600
Medium ingestion (10K events/sec) 8-16 CU ~RM 3,200-6,400
Heavy ingestion (100K events/sec) 32-64 CU ~RM 12,800-25,600
Query-heavy (complex KQL dashboards) 4-8 CU additional ~RM 1,600-3,200

Compare with Azure Data Explorer: | Workload | ADX Cost (RM/month) | |----------|---------------------| | Light (D11 node) | ~RM 4,500 | | Medium (D12 node) | ~RM 9,000 | | Heavy (D13 node) | ~RM 18,000 |

Fabric RTI is cost-competitive for light-to-medium workloads, especially when you factor in the eliminated infrastructure management.

Migration from Azure Data Explorer

If you are already running ADX and considering migration to Fabric RTI:

# 1. Export ADX table data to ADLS Gen2
az kusto data-connection event-hub create \
  --cluster-name adx-cluster \
  --database-name telemetry \
  --name adls-export \
  --storage-account storagemain \
  --storage-container fabric-import \
  --data-format json

# 2. Create Eventhouse in Fabric and configure ingestion from ADLS
# (via Fabric UI: Eventhouse → New → Data connection → ADLS Gen2)

# 3. Redirect applications to Fabric RTI endpoint
# Update connection strings from ADX cluster to Eventhouse

# 4. Validate query results match
# Run parallel queries on both ADX and Eventhouse, compare results

Migration timeline: 2-4 weeks for a typical ADX cluster with 5-10 tables and moderate data volume.

Key Takeaways

  1. Fabric Real-Time Intelligence eliminates infrastructure management for streaming analytics. Eventhouse, KQL, and Activator are fully managed — no cluster provisioning, scaling, or patching.
  2. Use Fabric RTI when you are already on Fabric. The integration with Lakehouse, Power BI, and the Fabric ecosystem is the primary value. Do not adopt it as a standalone streaming platform.
  3. Eventhouse is not a replacement for complex event processing. Use Stream Analytics or Flink for windowed joins, stateful processing, and exactly-once guarantees.
  4. Activator replaces custom alerting infrastructure. Monitor KQL query results and trigger actions without polling scripts or custom monitoring code.
  5. CDC replication (GA April 2026) bridges real-time and historical data. Operational databases can feed Eventhouse for real-time analysis and Lakehouse for historical analytics.

Resources