Hi @Ira_27 ,
Thanks for raising this in Microsoft Fabric Community.
Eventstream is primarily intended for real-time ingestion from sources like Event Hub, IoT Hub, or Kafka. In your case, since vendor data arrives as batch files via SFTP and is already being copied into ADLS, using Eventstream directly on those files is not the typical approach. This is because Eventstream operates on streaming records rather than directly reading and processing files from storage.
Microsoft Fabric Eventstreams Overview - Microsoft Fabric | Microsoft Learn
The blob-triggered notebook pattern you mentioned is a good fit for this scenario, as it processes files as they arrive and loads them into the Lakehouse efficiently. This aligns well with common batch or micro-batch ingestion patterns.
If you want to explore Real-Time Intelligence, you would first need to convert those files into events, for example by pushing rows into Event Hub or another streaming source, and then let Eventstream process them. This adds additional complexity and overhead without a clear benefit for file-based ingestion.
From a cost perspective, Eventstream typically runs continuously for streaming workloads and consumes capacity based on runtime and data throughput. Similarly, streaming notebooks remain active and consume compute even when data volume is low, which can make them more expensive and harder to manage compared to batch processing.
Microsoft Fabric Eventstreams Capacity Consumption - Microsoft Fabric | Microsoft Learn
Understanding CU consumption of streaming systems in Microsoft Fabric
For vendor data that is inherently batch-oriented, an event-driven batch approach (like your current design) is usually simpler, more cost-effective, and easier to maintain. Eventstream is better suited for scenarios where data is naturally generated as real-time events and requires low-latency processing.
Hope this helps. Please reach out for further assistance.
Thank you.
