Forum Discussion
Fabric SQL Database vs Warehouse
Hi VaibhavTiwari ,
As my colleague mentioned tayloramy , I would also go with a SQL Database, mainly because this kind of metadata-driven framework behaves much more like an OLTP workload.
A Warehouse can work, and in fact I used one for similar application scenarios when SQL Database in Fabric was not GA yet. In the end, I migrated it to Database.
The main issue is that when you start having many repetitive processes, writes, status updates, logs, etc., the CU consumption in the Warehouse becomes noticeably higher. You can optimize queries and processes, but there comes a point where, with enough frequency and concurrency, capacity usage still increases because it is not the type of workload the Warehouse is primarily designed for.
For this use case, I would go directly with SQL Database.
If this helped, please consider giving it a Like. If it solved your issue, please mark it as the Accepted Solution to help others facing the same problem.
Thanks
Yeah, either approach can work. We use a Fabric Warehouse for both metadata storage and pipeline logging, and we haven't experienced any performance issues.
In most metadata-driven ETL frameworks, the volume of metadata and log records is relatively small compared to fact and reporting data, so it's unlikely to stress a Warehouse. The Warehouse also provides a familiar SQL experience, making it easy to manage configuration tables, execution logs, audit history, and monitoring queries in a single place.
While SQL Database is often associated with OLTP workloads, I would choose the platform that best aligns with your team's skills and overall architecture. For metadata and pipeline logs, a Warehouse is generally more than capable and keeps everything within the Fabric ecosystem.
If this helped, feel free to give it a kudos or mark it as solution, helps others find it too.
Thanks!