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.
