Microsoft Fabric is an integrated platform that combines data analysis, storage, and processing, and has now added SQL Database to its offerings. It is currently still available as a preview. This development offers new possibilities for organizations familiar with SQL Server, but what are the differences compared to other storage options in Fabric, such as Lakehouse and Warehouse? And why should I choose SQL Server in Fabric over an Azure database? We’ll explore these questions in more detail in this blog post.
What is the SQL database in Microsoft Fabric?
The SQL database in Fabric is an enhanced version of Azure SQL Database, now integrated into the Fabric platform. It is a database that is easy to create and manage, works well with other Fabric components, and runs on the same SQL Database Engine as Azure SQL Database. Microsoft predicts a massive surge in app development driven by AI. Microsoft is responding to this trend with Copilot integration and GraphQL API integration for Fabric SQL Server.
Automatic OneLake Integration
Another important use case is the analytics capabilities offered by the Fabric SQL database. This is made possible by automatic replication to Onelake. When you create an SQL database, a Lakehouse item and a default Semantic model are automatically created. From a Power BI perspective, this provides a Direct Lake connection within your Semantic model, which prevents data duplication compared to the traditional import mode and reduces additional processing time.
The OneLake integration also offers capabilities for machine learning and data science tasks, for example, by using notebooks and Spark or Python engines. Within a Fabric environment, you can have multiple Lake House, Warehouse, or SQL database items, but the advantage is that you can write queries across these combined items.
Data processing.
There are several ways to get data into your Fabric SQL database. For example, you can use Fabric Pipelines (similar to Azure Data Factory) and, using a Copy activity (see image below), populate your database from any source. You can use Notebooks to write your data processing code, or you can use database mirroring. The latter is a relatively new option and is supported for several database types, including Azure. This is useful if you’re not allowed to run queries on the application database or if you want to offer more analytics capabilities than just a semantic model with import mode. Thanks to mirroring and automatic Onelake replication, the data is also near-real-time.
Azure SQL Database vs. Fabric SQL Database
If Ms Fabric is already available in your organization, you can use the Fabric SQL database without incurring additional licensing costs. At least that’s still the case during the preview period, but you’ll likely have to pay extra for automatic database backups in the future—though that will probably be a lot cheaper than an Azure license. The question is whether backup functionality is always necessary if you can replicate data from the source, and for development and testing, you can create a separate database and use deployment pipelines or Git integration. It is true, however, that a Fabric SQL database—just like other items in Fabric—consumes capacity units, so be sure to check whether this fits within your budget and, if necessary, run an analysis using the Microsoft Fabric Capacity Metrics app. Performance depends on the capacity size. Roughly speaking, 1 CU corresponds to 100 DTU of an Azure SQL Database. Aside from the costs, we can also make the following distinction between Fabric SQL Database and Azure Database.
| Criteria | Fabric SQL Database | Azure SQL Database |
| Architecture | SaaS: Fabric SQL is a Software-as-a-Service solution that is fully integrated into the Fabric platform. | PaaS: Azure SQL is a Platform-as-a-Service solution, which offers greater flexibility. |
| Workload Type | Analytical workloads, such as data analysis and reporting | Transactional workloads, such as inserts and updates |
| Data Integration | Integration with other Fabric components (Lakehouse, Power BI, etc.) | Standalone database solutions without direct Fabric integration |
| Data Format | Works with Delta tables in OneLake | Works with relational tables in traditional SQL format |
| Data Processing | Optimized for analytical queries | Optimized for fast transactional operations |
| Security Options | Basic Security Integrated into Fabric | Advanced security options such as TDE and firewall rules |
| Scalability | Scalability within the Fabric ecosystem and maximum database size. | Scalable with elastic pools and vertical scaling options |
| Costs | Included in Fabric capacity (CUs) | Depending on whether the plans are DTU- or vCore-based |
| Suitability for AI | Suitable for AI and machine learning thanks to Onelake synchronization and Copilot integration. | Less suitable for direct AI workflows, but good for data storage |
Difference Between Fabric Lakehouse and Warehouse
There is certainly some overlap between the various storage options in Fabric, but there are also differences. Based on practical experience, there are a number of things you have to handle slightly differently in Lakehouse and Warehouse. For example, you cannot send data directly from a source to a Warehouse via a pipeline; instead, you must first load the data into Lakehouse. Defining primary keys and using SQL MERGE statements are not possible, and some SQL code on a Lakehouse can only be executed via a notebook. If we analyze the various storage options within Fabric, we can broadly identify the following use cases.
Fabric SQL Database → For small to medium-sized datasets (up to 4 TB). For analysts and BI teams with SQL knowledge who want to use both Power BI reports and data storage and processing on a single cloud platform for structured data.
Warehouse → For large datasets and BI reports; suitable for data engineers and analytics teams who primarily have SQL skills and work with structured and semi-structured data, but also want the option to work with Spark.
Lakehouse → For big data, machine learning, and AI; for data science and engineering experts with Spark knowledge who want to work with both structured and unstructured data.
For more technical details on the differences Microsoft has made to this The site also includes a table comparing Lakehouse, Warehouse, Eventhouse, SQL Database, and Power BI Datamart. Incidentally, I would ignore the last option in this comparison table—Power BI Datamart—because it has been in preview for a few years now and will likely never reach production status due to the emergence of other storage options.
Conclusion
The introduction of the SQL database in Microsoft Fabric offers organizations a proven database within an integrated platform that is easy to set up and requires minimal management. By making the right choice between a Lakehouse, Warehouse, or SQL database in Fabric—or a combination of these—based on specific needs and data types, organizations can further optimize their data infrastructure and derive greater value from their data platform and reporting system.
