Azure Stream Analytics
Azure Stream Analytics is a fully managed stream processing engine using a SQL dialect extended with temporal constraints, running in the cloud or on IoT Edge with the same tools and query language.
LicenseCommercial
DeploymentManagedHybrid
PricingSubscription
Operational complexityLow
WorkloadStreaming
Use it when
- The stack is Azure and the job is SQL: Event Hubs or IoT Hub in, Synapse, Cosmos DB, Functions, or Power BI out, with a live dashboard as a native sink.
- The same logic must run at the edge; the identical query language and tooling deploy to IoT Edge containers next to the devices.
- Nobody wants to size a cluster; jobs are billed per streaming unit and can be resized while running.
- Analysts should participate; a no-code editor sits beside the query language, and JavaScript UDFs extend it.
Think twice when
- Sources or sinks live outside Azure; connectivity is almost exclusively Azure services, with Kafka input the only outsider and its output still in preview.
- State is large or long-lived; the service manages state in memory with temporal state capped at seven days.
- The logic outgrows SQL; there is no code-level API, and complex jobs migrate to Flink or Dataflow-shaped engines.
How it runs
Fully managed: write the query, attach inputs and outputs, choose streaming units; the service (built on the Trill engine) checkpoints, recovers, and guarantees exactly-once processing with at-least-once delivery to most sinks. The same job ships as an IoT Edge container for on-premises execution.
Details
CompareHow Azure Stream Analytics answers the questions Stream Processing turns on.
Stream Processing
| How it works | |
| Processing model | Fully managed continuous SQL over in-memory state; watermark progress is the only output trigger, so there are no partial aggregates |
| APIs | SQL-like query language; no-code editor; JavaScript UDFs and aggregates, Azure ML functions (C# retired in 2024) |
| Windowing | Tumbling, hopping, sliding, session, snapshot |
| Event time and lateness | Out-of-order and late arrival tolerances are configurable, each set to drop or adjust; events over five minutes early are always dropped; substreams give a watermark per key |
| State backend | Managed by the service and held in memory, with temporal state capped at seven days; checkpoints and replay recovery |
| Delivery guarantee | Exactly-once processing; At-least-once delivery to most sinks |
| Reading results | Through outputs; Power BI is a native one, so a dashboard can be the sink |
| Running it | |
| What you run | Nothing: a managed Azure job sized in streaming units; the same engine ships as an IoT Edge container for on-premises jobs |
| Scaling | Streaming units can be changed while the job runs, though a non-partitioned output or mismatched PARTITION BY steps restrict which values are available |
| Connections | |
| Connectors | Azure services almost exclusively: Event Hubs, IoT Hub, Blob and ADLS Gen2 in; Synapse, Data Explorer, Cosmos DB, SQL, PostgreSQL, Power BI, Functions, Service Bus and Table storage out. Kafka is the only outside input and its output is still preview |
Alternatives to Azure Stream Analytics
