It would be valuable for Fabric Eventhouse to provide a built-in, standard replication service for cross-region data redundancy and failover. Today, there is no native solution, and teams must rely on custom approaches.   A first-class, Fabric-native replication capability would simplify BCDR and improve reliability for production workloads. This includes built-in cross-region redundancy and failover for regional outages, as well as native data replication scenarios such as Azure Data Explorer (ADX/Kusto) to Fabric Eventhouse (KQL DB) and Fabric Eventhouse to Fabric Eventhouse across regions. ... View more

Hi all, I would like to submit a feature request regarding the Microsoft Fabric Eventstream REST API. Currently, it is possible to programmatically: Create an Eventstream Update its definition Configure an Eventhouse destination (including database and table mapping) However, there is a missing step that cannot be performed via API: After publishing the Eventstream topology, the final step "Configure KQL Data Connection" (available in the UI) is required to fully enable ingestion into the Eventhouse table. At the moment: This step is only available through the UI There is no documented or supported API to complete this configuration This creates a blocker for full automation and CI/CD scenarios   For teams working with Infrastructure as Code and automated deployments, the inability to configure the KQL Data Connection programmatically means: Eventstream deployments cannot be fully automated Manual intervention is required after each deployment CI/CD pipelines are incomplete Requested enhancement Provide an official and supported way to: Configure KQL Data Connection via REST API Or include this configuration within the Eventstream definition payload This could be implemented as: A new API endpoint for managing Eventhouse ingestion connections or Extending the Eventstream definition schema to include this configuration This capability would significantly improve automation scenarios and align Eventstream with other Fabric resources that already support full API-based deployment. Thanks for considering this request. ... View more

When importing a file from an Azure Storage Account, by default it can be processed in several formats. XML, a fairly common format, is not currently supported and therefore cannot be parsed. It would be good to have this option.   https://blog.fabric.microsoft.com/en-us/blog/continuous-ingestion-from-azure-storage-to-eventhouse-preview?ft=All  ... View more

Currently, EventStream supports adding Event Hub as an input source using the SAS Key authentication method. Please add support for Managed Identity–based authentication so that EventStream can align with Microsoft’s Safe Secrets and keyless authentication best practices. This would improve security posture, eliminate secret rotation overhead, and enable seamless integration with Azure resources using RBAC. ... View more

Here the original discussion   https://community.fabric.microsoft.com/t5/Fabric-platform/azure-kusto-spark-enabling-writeMode-to-KustoStreaming-is-not/m-p/5138226   Basically, I would like to use KustoStreaming which is a option/feature developed in azure-kusto-spark connector to leverage the power of streaming ingestion into kusto table where StreamingIngestion policy is enabled. This functionality is not available in the version  spark-kusto-synapse-connector_3.5_2.12-1.5.1.jar However, is implemented and available in later versions.  Documentation of connector indicates that KustoStreaming is appropiate in the business scenarios where Low latency is explicitly required azure-kusto-spark/docs/KustoSink.md at master · Azure/azure-kusto-spark · GitHub   ... View more

I have a potential client for streaming data and real time dashboards. I'm setting up a mock up, pushing data every few seconds. Everything is connected, but the Real Time Dashboard is 15 MINUTES behind, and losing ground. I understand that Microsoft took away the ability to set a dashboard to refresh automatically and refresh is now controlled by MS/Fabric.  Please bring back the ability to have a real time dashboard configure for automatic refreshes. If you are worried about capacity or for whatever reason it was disabled, start broad, like every minute instead of every few seconds. Honestly, what good is 'real time' data of I cannot actually see it in real time? ... View more

Description: We are currently using Microsoft Fabric with Eventhouse -> Shortcut -> Lakehouse -> Snowflake Iceberg architecture. We have observed that datetime values are stored with millisecond precision (3 digits), for example: 2025-05-03 08:09:34.301 However, downstream systems like Snowflake Iceberg require microsecond precision (6 digits), such as: 2025-05-03 08:09:34.301000 This mismatch leads to compatibility issues when reading Fabric-generated Parquet files in Iceberg tables. Current behavior: Fabric stores datetime values with millisecond precision (scale 3), and there is no built-in way to enforce or convert to microsecond precision. Expected behavior: Fabric should support configurable datetime precision (e.g., 3, 6 digits) or automatically pad milliseconds to microseconds when required, ensuring compatibility with downstream systems like Iceberg. Impact: This is a critical blocker for integrating Fabric Lakehouse with modern data platforms like Snowflake Iceberg and affects enterprise adoption of Fabric in production environments.     ... View more

When defining a follower database (or shortcut) in Fabric RTI (Eventhouse), the follower database in Fabric folllows the entire ADX source Database But in ADX when create a data share, which is the similar concept, it's possible to share only certain tables as explained here  https://learn.microsoft.com/en-us/azure/data-explorer/data-share#sharing-tables It will be good to have the same kind of sharing logic for Fabric RTI as we have for ADX : to be aligned in terms of capabilities and have a more granular control of what is to be shared.   ... View more

As individual teams coming up with AI agents/ Agentic workflows. It would be great to have a shared Kusto MCP server that is maintained/deployed by Kusto team, so that individual teams at microsoft doesnt have to take the code and deploy individual instances. It just adds overhead when it comes to maintenance to get any fixes/upgrades.  @Anshul ... View more

Revision: Be able to enable OneLake Availability on the follower so the business users can enable it as well as inherit the permissions from the follower rather than the primary.     Problem: Currently, downstream consumers who need to query Eventhouse data via Lakehouse shortcuts must have read access to the primary Eventhouse tables. This creates two main challenges: Security / Governance: Users can access the primary Eventhouse, which may not be desirable. Operational Overhead: Teams must schedule incremental .export commands for each table to provide Lakehouse access, which is cumbersome and difficult to manage at scale.   Proposed Solution: Introduce a feature that allows Eventhouse to automatically export data to Lakehouse shortcuts without requiring users to have read access to the primary tables. Benefits: Downstream consumers can query Lakehouse shortcuts without impacting Eventhouse compute or hitting query limits. Eliminates the need to schedule per-table exports manually. Maintains strict security and governance by preventing direct access to the primary Eventhouse tables. Supports both full and incremental exports, keeping Lakehouse data fresh and up-to-date. ... View more

Eventhouses now support Git Integration, which is a great step forward. But when you look at what actually gets pushed to Git, there is an immediate version control concern: the entire Eventhouse definition is stored as one large .kql file. From a DataOps perspective, this is not ideal. Large monolithic files are difficult to review, hard to merge across teams, and almost always produce noisy diffs. When you look at more mature version controlled artifacts in Fabric, such as Power BI’s move to TMDL or the PBIR format, the direction is clear: break complex assets into smaller, structured, independent files. TMDL separates tables, measures, relationships, expressions, and roles into their own files. PBIR moved away from the single report.json and now stores each page and visual independently. This level of granularity makes teamwork easier, improves change tracking, and strengthens DevOps workflows. Eventhouse should follow the same pattern. Instead of one large script, the service could output a clean directory structure that separates tables, policies, ingestion settings, functions, and materialized views. This would: Make merges safer and easier Let team members work on different components without conflicts Improve the clarity of version history Support more consistent automation and testing patterns If Fabric adopted a multi file structure for Eventhouse artifacts, it would enable stronger collaboration across Power BI and data engineering teams and make Eventhouse a first class citizen in real DataOps workflows. ... View more

We autoprovision sites around the world that have an eventhub to send us data but we have to have a person use the UI to connect their eventhub to their eventhouse to be used by powerbi for real time intelligence. Please add this functionality to the REST api as we were able to do this function before with ADX admin sdk. copilot suggested dataStreams methods.. POST https://fabric.microsoft.com/v1/workspaces/<workspaceId>/eventhouses/<eventhouseId>/datastreams Content-Type: application/json Authorization: Bearer <your_token> { "name": "MyDataStream", "source": { "type": "EventHub", "namespace": "<your_eventhub_namespace>", "eventHubName": "<your_eventhub_name>", "authentication": { "type": "ConnectionString", "value": "<your_eventhub_connection_string>" } }, "destination": { "type": "Eventhouse", "database": "<your_database_name>", "table": "<your_table_name>" } } we would want to add the format and ingestion mapping to use. ... View more

I'd like the ability to run all queries in a fabric realtime dashboard on a schedule unattended in order to pre-populate the query-results-cache in Kusto so that when i open the dashboard after the scheduled time, queries run much faster ... View more

We have a dataset which for which I am working on a visualization. With incremental refresh, each time I publish a change I have lost historical data. From what I can see there is no way to run refreshes as if I was starting from a past date. If the data I am looking at is all timestamped, I think it would be a great feature to be able to run the queries on different timeframes in order to populate this historical data ... View more

User creates a Materialized view in EH. Have the ability to make that MV available in OneLake. The workaround is for the the application to copy over the MV on a periodic basis to Onelake. I would like this capability in the platform.  ... View more

I have several use cases where I want to embed a Real-Time Dashboard with Power BI Embedded which isn't currently supported. ... View more

I think enabling OneLake availability directly from a follower Eventhouse would be a valuable feature. This idea builds on another proposal I shared earlier that currently appears to be stuck in “Needs clarification.”   In our architecture, we treat the primary Eventhouse strictly as ingestion-only, while the follower Eventhouse is used exclusively for downstream consumption.   Ideally, business users should have access only to the follower Eventhouse, never the primary. However, today when we enable OneLake availability and create a shortcut to a Lakehouse, users must be granted access to the primary Eventhouse in order to see the table. This breaks our intended segregation model and introduces a risk, since business users can now directly query the primary Eventhouse—something we explicitly want to avoid.   While the follower Eventhouse is read-only, it is already the surface area exposed to downstream consumers. Allowing OneLake availability to be enabled from the follower Eventhouse would preserve this separation of concerns and eliminate the need to grant any access to the primary.   This would also empower downstream users to enable OneLake availability and create their own shortcuts, rather than requiring the development team to configure it on the primary Eventhouse and manage narrowly scoped access to individual primary tables. Overall, this change would better support secure, ingestion-vs-consumption–aligned architectures and reduce unnecessary operational overhead. ... View more

At the moment it is possible to assign AllDatabasesAdmin and AllDatabasesViewer to Eventhouse inheriting the Admin or Viewer permission of the workspace, implying that Admin or Viewer role is assigned to all Eventhouse artifacts in the workspace. It would be great if AllDatabasesAdmin and AllDatabasesViewer can be assigned to individual Eventhouse artifacts in the workspace. ... View more

Azure AI Agent service (preview) allows you to create agents to perform different tasks. These agents can have “knowledge tools” for grounding. At the moment the only knowledge tools available are: Bing search Azure AI search File Search   I don’t know what are your plans, but adding Eventhouse to the knowledge tools may be a good idea As you know almost all DB have vector DB capabilities. I will expect Cosmos and MSSQL to be next to integrate. So Fabric Eventhouse must be integrated as well.  IMHO ... View more