SQL Database in Fabric: A New Paradigm for Cloud Databases with One-Click AI Integration

Microsoft is extending SQL capabilities from on-premises to the cloud and then into the unified Fabric data platform. In a recent technical demo, Sukhwant Kaur, Senior Product Manager for SQL Database and Fabric product teams, provided a detailed walkthrough of the product's design philosophy, core capabilities, and typical scenarios. Based on that demo, this article outlines how SQL Database in Fabric is reshaping the way developers build intelligent applications through three pillars: simplified, autonomous, and AI-optimized.

What is Fabric: One Platform for All Data Workloads

Before diving into SQL Database, it's worth understanding the foundation it sits on. Microsoft Fabric is Microsoft's unified data platform for AI transformation, bringing together databases, data integration, analytics, real-time intelligence, and BI workloads into a single platform. All Fabric workloads share the same governance model and OneLake storage layer, which means no data silos, no duplicate governance, and no need to stitch together separate services. Copilot is built in throughout the platform, assisting everything from writing queries to generating insights.

SQL Database in Fabric is built within this framework, with the underlying engine identical to SQL Server and Azure SQL, so developers can continue using familiar tools like VS Code and SSMS.

OneLake is Fabric's tenant-level unified logical data lake—essentially a shared "OneDrive for data" for the entire organization. All Fabric workloads (including SQL Database, Data Factory, Power BI, Real-Time Intelligence, etc.) write data in Delta Parquet format to this single storage account, with no need to move or copy data between services. OneLake supports Shortcuts, which can reference data in external storage such as ADLS Gen2 and S3 without creating copies, while providing a unified entry point for permissions and governance. This single data foundation architecture is the fundamental reason Fabric can eliminate data silos and avoid duplicate governance, and it's also the prerequisite for SQL data being directly queryable across engines after automatic mirroring.

Three Design Pillars: Simplified, Autonomous, AI-Optimized

The product team designed SQL Database in Fabric around three pillars, and the demo followed this structure. The presenter also shared typical scenarios already observed: operational data stores, event-driven applications, Power Apps, web applications, metadata-driven pipelines, vector and similarity search, RAG applications, reverse ETL, Power BI write-back, and reference data storage.

Simplified: Minute-Level Creation, Automatic Mirroring to OneLake

The core goal of "simplified" is to let users spend time solving business problems rather than managing databases. The creation process requires only naming the database—no server configuration—and completes in tens of seconds, with sample data allowing queries to start within minutes. The editor provides a full T-SQL experience with IntelliSense, and Copilot is built into the editor to help write queries, generate insights, and even troubleshoot performance issues. Billing is consolidated through the Fabric capacity model: one capacity, one bill.

More distinctive is the automatic mirroring feature. SQL data is replicated to OneLake in near real-time with zero configuration, happening automatically when the database is created. This delivers threefold value: operational and analytical data are unified, eliminating the need to build and maintain ETL pipelines; data lands in the open-source Delta format, accessible to all users; and through shortcuts and SQL analytics endpoints, data can be queried across platforms without copying. Previously, analytics on Azure SQL required building ETL to move data to a data warehouse—now that step is completely eliminated.

The Delta format (Delta Lake) is an open-source table format built on top of Parquet that brings database-level capabilities such as ACID transactions, schema evolution, and time travel to data lakes. It records each write through a transaction log (_delta_log), making concurrent reads/writes and rollbacks reliable operations. Adopting Delta as the default open format in Fabric means data mirrored from SQL Database can be efficiently read not only by in-Fabric engines like Spark notebooks and Power BI Direct Lake, but also directly consumed by external platforms such as Databricks, Trino, and Snowflake without proprietary format conversion. This openness is the format foundation that truly bridges "operational data" and "analytical data."

Autonomous: Handing Operational Complexity to the Platform

Customer feedback highlights the pain points of complex database platform management and difficult technology selection. The product team's approach is to automate every aspect of configuration and management. Every SQL Database in Fabric is serverless, provisioned instantly by Fleet Manager, with the platform handling scaling and management after one-click creation. Databases automatically get zone-redundant high availability, with resources replicated across regions without configuration; intelligent query processing capabilities such as automatic plan correction can detect query plan regressions and automatically revert to previous plans, and missing indexes are automatically detected and created. Backup and metering are fully managed by the system, supporting point-in-time restore to any point.

On the security front, Microsoft Entra authentication is fully promoted for passwordless authentication, and auditing automatically collects key events such as login attempts and security changes. Data encryption at rest uses Microsoft-managed keys by default, while organizations with strict governance requirements can use their own keys in Azure Key Vault. With Microsoft Purview integration, SQL databases can be labeled by sensitivity like other Fabric items, with centrally managed policies automatically applied.

AI-Optimized: Vector Search and RAG Within T-SQL

This was the most substantial part of the demo. SQL Database in Fabric natively supports the vector data type, can directly connect to Azure OpenAI models, and enables generating vector embeddings, performing similarity search, and building RAG applications entirely in T-SQL—no middleware or external pipelines required. Data and embeddings can reside in the same location.

The demo showed the complete flow: first create a database-scoped credential, then define an embedding model with CREATE EXTERNAL MODEL, and then use the AI_GENERATE_EMBEDDINGS function to generate embeddings for a product table and write them to a new column. During retrieval, the user's question (e.g., "I want an affordable red bicycle") is converted to a vector, and the closest entries are found using vector distance functions. This semantic search is the foundation of RAG.

The presenter explained RAG in plain terms: large language models have broad knowledge but don't know your domain data. Vector search retrieves domain context and sends it along with the question to the model—essentially setting guardrails for the model to answer only based on the given context rather than fabricating from "wild" knowledge. In the demo, two stored procedures work together: one assembles the payload and calls an external REST endpoint, and the other performs similarity search and calls the former. In actual testing, when a user asked about a "red portable mountain road bike," the system recognized there was no red model available and instead recommended another bestselling model—responding like a real sales assistant.

For teams looking to build AI applications with low code, the Fabric ecosystem offers a Data Agent feature: click to create and point to SQL data to generate a chat application; notebooks, data pipelines, dataflows, and Power BI in Direct Lake mode can also participate.

Vector embeddings are the process of mapping unstructured content such as text and images into high-dimensional floating-point arrays, where semantically similar content is closer in vector space. Retrieval typically uses cosine distance or Euclidean distance to measure similarity, which is what vector distance functions in SQL Database are based on. RAG (Retrieval-Augmented Generation) leverages this: first retrieve the most relevant records from a domain knowledge base, concatenate them as context into the prompt, and then have the large language model generate an answer. Compared to fine-tuning models, RAG enables models to master private data without retraining, and answers can be traced back to source records—which is why it's widely adopted in enterprise knowledge Q&A, customer service assistants, and similar scenarios. The "guardrails for the model" metaphor in the article points precisely to this mechanism of answering based on given context and suppressing hallucinations.

Migration and Source Control: Smooth Transition from Existing Databases

The demo also covered two engineering practice topics. The first is the migration tool: select a DACPAC file as the source, and the validation step lists which objects can migrate smoothly and which have issues, with results exportable to Excel, CSV, or JSON. After selecting the target workspace and database name, migration begins; upon completion, the tool lists discovered issues, and users can fix each one with AI-assisted scripts, then complete data movement through a copy job in Fabric. Before use, ensure the workspace has active capacity, the on-premises data gateway is installed and verified, and a gateway-enabled Fabric SQL connection has been created.

The second is source control and CI/CD. Every SQL Database in Fabric can be source-controlled, with the Fabric web interface directly supporting GitHub and Azure DevOps. The workflow has three stages: commit database objects to a Git repository in Fabric and sync with the live database; develop with SQL projects in VS Code or Visual Studio, where the build process validates object references and catches syntax issues; and finally automate deployment via the SQL Package command-line tool, supporting bacpac import/export or iterative DACPAC deployment in CI/CD environments. The demo walked through the complete flow: from editor commit, modifying data in VS Code, creating a script and committing/pushing, to deploying through a deployment pipeline to production and confirming deployment completion in the table.

DACPAC (Data-tier Application Package) is a data-tier application package in the SQL Server ecosystem—essentially a zip file containing database object definitions (schema) rather than data itself. It is generated by building a SQL project and can be used to deploy or upgrade database structures, and is one of the core inputs for the SQL Package command-line tool. In contrast, bacpac contains both schema and data, suitable for full database migration or import/export. In CI/CD workflows, DACPAC is often used for incremental deployment: the tool compares the target database with the DACPAC and automatically generates the necessary change scripts. Understanding the difference between DACPAC and bacpac helps determine when a migration scenario only needs to sync structure versus when data must be moved along with it.

End-to-End Architecture: One Database Connecting the Entire AI Chain

The demo concluded with an architecture diagram that many customers are already adopting. The SQL database sits at the center, connecting to Microsoft Foundry to generate embeddings stored in the same location; data is mirrored to OneLake in near real-time, allowing business users to create Power BI reports based on OneLake without adding load to the SQL database, while analysts can use notebooks to combine some data with other OneLake items. On the consumer side, an API layer can be created via GraphQL, with endpoints handed to developers to build chatbot applications—all achievable with low code or even no code.

From this demo, it's clear that SQL Database in Fabric is not just another cloud database, but rather compresses database, analytics, governance, and AI capabilities into a single pipeline. For teams already using SQL Server or Azure SQL, the migration barrier is deliberately kept low; for developers wanting to quickly validate RAG-type applications, vector capabilities are built directly into T-SQL, eliminating the engineering cost of setting up external vector stores and sync pipelines. This "database as the foundation for AI applications" approach is worth considering when making technology choices.