Understanding Fabric Eventstream Pricing
In this blog post, we’ll walk through Eventstream’s pricing model to give you a clear understanding of how it works and help you navigate it with confidence.
By the end of this post, you will be able to:
- Comprehend how Eventstream pricing is structured across its components.
- Understand the relationship between Eventstream components and billing meters.
- Review detailed pricing examples to support precise and confident cost estimation.
Eventstream Components & Cost Drivers
First, let’s summarize the components of a Fabric Eventstream:
- Input sources
- Streams (default and derived)
- Operators (using No-Code or SQL)
- Destinations
Each component maps to one or more of the four Eventstream operation types (billing meters). These operation types define how Eventstream activity is represented in the Fabric Capacity Metrics app and how they contribute to Fabric consumption.
The following reference table outlines how Eventstream components correspond to each operation type. Note that certain components may map to one or more operation types:
| Eventstream Component | Operation Type | Description of Operation Type | Operation unit of measure | Fabric consumption rate |
| Eventstream Per Hour | Flat charge | Per hour | 0.222 capacity unit (CU) hours | |
| Streams (default and derived) | Eventstream Data Traffic Per GB | Data ingress and egress volume in default and derived streams (includes 24-hour retention) | Per gigabyte | 0.342 CU hours |
| Operators and some input sources | Eventstream Processor Per Hour | Computing resources that the processor consumes | Per hour | Starts at 0.778 CU hours and autoscales 2 per throughput |
| Input sources leveraging connector | Eventstream Connectors Per vCore Hour | Computing resources that the connectors consume | Per hour | 0.611 CU hours per vCore |
Table listing Eventstream pricing components with their operation types, descriptions, units, and consumption rates, including hourly charges, data traffic per GB, processor usage, and connector vCore costs.
Breakdown of each component with associated operation type:
Flow diagram: Input Source → Default Stream → Operator → Derived Stream → Destination.
Input Source
Input source(s) represents where your data comes from in an Eventstream. You can connect to different types of sources, and pricing is based on how they operate.
Most Eventstream sources fall under ‘connectors’, meaning they incur the cost of Connector vCore per hour meter (e.g., Azure SQL DB, Cosmos DB, Service Bus, etc.).
Other sources do not incur the connector cost and instead incur the Eventstream Processor Per Hour meter charge (e.g. Azure Event Hubs, Azure IoT Hub).
Billing is determined by how each source brings data into Fabric.
Default and Derived Streams
There are two types of streams in an Eventstream topology. Default Stream is present in all Eventstreams, and additionally, you can create a Derived Stream.
A derived stream refers to a logical stream of data which is created by applying transformations to the default stream after adding operators such as filtering and aggregations. Derived streams can be accessed independently from default streams for additional consumption or analysis through the Real-Time Hub.
For billing purposes, the Eventstream Data Traffic per GB meter is calculated based on the volume of data entering (ingress) and exiting (egress) each stream within your Eventstream topology, as illustrated below:
Operators
Operators (configured through no-code options or SQL) enable the application of processing logic within your Eventstream, including filtering, enrichment, and routing. Billing is determined by the number of processing routes defined in the Eventstream, representing the paths through which data flows from sources, through processing steps, to their respective outputs:
The Eventstream Processor Per Hour meter is determined by the number of processing routes defined within your Eventstream.
Separately, the throughput setting serves as a lever to manage how the system scales. Eventstream automatically adjusts compute resources to maintain low latency, and billing reflects the compute that is actually consumed. By configuring throughput, you establish an upper limit on system scaling, which can also support cost management.
Destinations
In Fabric Eventstreams, destinations fall into two categories:
- Push destinations perform processing and send data, they are charged per the Eventstream Processor Per Hour meter, these include:
- Lakehouse
- Eventhouse (with transformation applied)
- Activator
- Pull destinations fetch data from your Eventstream (rather than Eventstream pushing the data), these destinations do not incur a processing cost on the Eventstream side, these include:
- Eventhouse (Direct ingestion)
- Custom endpoint
Pricing Walkthrough: Example Scenarios
We will now examine several examples to calculate CU consumption based on the Eventstream components involved.
Example 1: Custom endpoint to Eventhouse (direct ingestion, no processing)
The set-up:
- Source: Custom endpoint
- Destination: Eventhouse (pull: direct ingestion)
- Data volume: 1 GB per day (or ≈ 0.04 GB per hour)
- Processing: Passthrough
- Eventstream uptime: Continuous, 24 hours/day
For this set-up, the meter calculation would be as follows:
| Operation in Capacity Metrics App | Description | Operation unit of measure | Fabric consumption rate | Calculation |
| Eventstream Per Hour | Flat charge | Per hour | 0.222 CU hour | 0.22 per hour |
| Eventstream Data Traffic per GB | Data ingress & egress volume in default and derived streams (Includes 24-hour retention) | Per GB | 0.342 CU hour | 0.08 GB (.04 GB ingress+.04 GB egress) of data X .342 = 0.03 per hour |
| Eventstream Processor Per Hour | Computing resources consumed by the processor | Per hour | Starts at 0.778 CU hour and autoscale per throughput | 0 X .778 = 0 per hour |
| Eventstream Connectors Per vCore Hour | Computing resources consumed by the connectors | Per hour | 0.611 CU hour per vCore | 0 X .611 = 0 per hour |
| SUM = 0.25 CU per hour |
This Eventstream topology consumes 0.25 CU per hour.
Recommended SKU for this Eventstream alone: F2 (87% unused)
Example 2: Content based routing with 1 connector source, processing logic, and 2 destinations.
The set-up:
- Source: 1 connector source (for example Azure SQL CDC)
- Destination: 2 destinations (Eventhouse tables with pre-processing)
- Data volume: 1 GB per day (or ≈ 0.04 GB per hour)
- Processing: Filtering and routing data
- Eventstream uptime: Continuous, 24 hours/day
For this set-up, the meter calculation would be as follows:
| Operation in Capacity Metrics App | Description | Operation unit of measure | Fabric consumption rate | Calculation |
| Eventstream Per Hour | Flat charge | Per hour | 0.222 CU hour | 0.22 per hour |
| Eventstream Data Traffic per GB | Data ingress & egress volume in default and derived streams (Includes 24-hour retention) | Per GB | 0.342 CU hour | 0.12 GB (.04 GB ingress + (2 x .04 GB egress)) x .342 = 0.04 per hour |
| Eventstream Processor Per Hour | Computing resources consumed by the processor | Per hour | Starts at 0.778 CU hour and autoscale per throughput | 2 X .77 = 1.55 per hour |
| Eventstream Connectors Per vCore Hour | Computing resources consumed by the connectors | Per hour | 0.611 CU hour per vCore | 1 X .611 = 0.61 per hour |
| SUM = 2.42 CU per hour |
Table showing Eventstream capacity metrics with operation types, descriptions, units, consumption rates, and example calculations. Includes hourly charges, data traffic per GB, processor costs, connector vCore costs, and a total of 2.42 CU per hour.
This Eventstream topology consumes 2.42 CU per hour.
Recommended SKU for this Eventstream alone: F4
Example 3: Aggregation processing with scaling traffic (comparing 1 GB/hour vs. 10 GB/hour).
This example shows how the same processing logic results in different processing charges based on the amount of data. As traffic increases, Eventstream scales compute, and the Eventstream Processor Per Hour cost grows accordingly.
The set-up (common across except for traffic levels):
- Source: 1 connector source
- Destination: Data Activator
- Data volume: varies by scenario
- Example 3A: 1 GB/hour
- Example 3B: 10 GB/hour
- Processing: 1 aggregation operator
- Eventstream uptime: Continuous, 24 hours/day
Example 3A: 1 GB per hour
| Operation in Capacity Metrics App | Description | Operation unit of measure | Fabric consumption rate | Calculation |
| Eventstream Per Hour | Flat charge | Per hour | 0.222 CU hour | 0.22 per hour |
| Eventstream Data Traffic per GB | Data ingress & egress volume in default and derived streams (Includes 24-hour retention) | Per GB | 0.342 CU hour | 2 GB (1 in + 1 out) × 0.342 = 0.68 per hour |
| Eventstream Processor Per Hour | Computing resources consumed by the processor | Per hour | Starts at 0.778 CU hour and autoscale per throughput | 1 × 0.778 = 0.77 CU per hour |
| Eventstream Connectors Per vCore Hour | Computing resources consumed by the connectors | Per hour | 0.611 CU hour per vCore | 1 × 0.611 = 0.61 per hour |
| SUM = 2.28 CU per hour |
Recommended SKU for Example 3A: F4
Example 3B: 10 GB per hour
| Operation in Capacity Metrics App | Description | Operation unit of measure | Fabric consumption rate | Calculation |
| Eventstream Per Hour | Flat charge | Per hour | 0.222 CU hour | 0.22 per hour |
| Eventstream Data Traffic per GB | Data ingress & egress volume in default and derived streams (Includes 24-hour retention) | Per GB | 0.342 CU hour | 20 GB (10 in + 10 out) × 0.342 = 6.84 per hour |
| Eventstream Processor Per Hour | Computing resources consumed by the processor | Per hour | Starts at 0.778 CU hour and autoscale per throughput | 1 × (0.778 x 3*) = 2.33 CU per hour *1 base rate (2.33 CU hours) |
| Eventstream Connectors Per vCore Hour | Computing resources consumed by the connectors | Per hour | 0.611 CU hour per vCore | 1 × 0.611 = 0.61 per hour |
| SUM = 10.00 CU per hour |
Table showing Eventstream capacity metrics with operation types, descriptions, units, consumption rates, and example calculations. Includes hourly Eventstream charge, data traffic for 20 GB per hour, processor autoscale cost, connector vCore cost, and a total of 10.00 CU per hour.
Recommended SKU for Example 3B: F16
To Summarize:
The cost of operating Eventstream is determined by several factors:
- Type and number of input sources
- Type and number of destinations
- Compute required for processing
- Data volume (ingress and egress) from streams
- Eventstream uptime
While this blog post helps calculate CU consumption, we recommend running your Eventstream in a realistic, steady-state configuration for a period of time—ideally 24 hours—to observe actual consumption patterns.
The Microsoft Fabric Capacity Estimator can also be used to assist in cost planning, as it estimates the capacity requirements of an Eventstream based on your input parameters. It is important to consider any additional Fabric workloads, such as Eventhouse, Lakehouse, or Notebooks, since all services draw from the same capacity pool.
We’d Love Your Feedback!
If you found this blog post helpful, please give it a thumbs up and share your feedback with us.
Questions? Reach out via email at askeventstreams@microsoft.com.
You can also submit feedback or feature requests on Fabric ideas and join the conversation with fellow users in the Fabric Community.
