Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!The Power BI Data Visualization World Championships is back! It's time to submit your entry. Live now!
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.