TL;DR
SQL Database in Microsoft Fabric is a database for operational applications. It runs the same engine as Azure SQL and keeps data in OneLake. Applications and analytics then read one governed copy. It fits departmental apps, line-of-business systems, and AI features that need fresh data. It does not replace SQL Server for every workload. Very large transactional systems and giant warehouses belong elsewhere.
Key Takeaways SQL Database in Fabric runs the Azure SQL engine, so existing T-SQL skills transfer with modest retraining. Its data lands in OneLake in an open format, which removes a separate copy for analytics. Capacity pricing replaces the per-database billing model, so cost planning changes shape. Compatibility gaps decide whether a workload can move. Departmental and line-of-business systems fit best; large OLTP and giant warehouses do not. Governance matters more here because operational and analytical work share one platform. Watch on YouTube
Azure to Fabric Migration Made Simple with Kanerika
A walkthrough of what actually changes when an Azure SQL workload moves into Fabric, and the checks that keep the first cutover from slipping.
Why Enterprise Architects Are Reconsidering Where Transactional Data Lives Enterprise architects now get asked to put operational databases and analytics on one platform, and to do it without a second copy of the data. Microsoft’s answer is SQL Database in Microsoft Fabric, a transactional engine that writes straight into OneLake. The engine looks familiar. The decisions around it do not.
Fabric removes that wall by placing a transactional database beside the lakehouse and warehouse. Adoption is still a deliberate choice. A database that runs on Azure SQL but behaves differently under load forces architects to ask harder questions about workload fit.
Get that placement right and reporting tightens up. By contrast, get it wrong and you move a fragile system onto an engine that was never built for it.
Understanding SQL Database in Microsoft Fabric and Its Role in Modern Data Architectures SQL Database in Microsoft Fabric is a fully managed transactional database that lives inside the same platform as your lakehouse and warehouse. It runs the Azure SQL Database engine, so teams keep the T-SQL surface and client tools they already know. What changes is where the data sits and how the rest of the platform reaches it.
Instead of an isolated server, the database writes its tables to OneLake in an open Delta format. As a result, analytics engines can read the same rows without a separate extract and load pipeline. That single-copy model is the whole point of the workload.
The convenience carries trade-offs. The engine is tuned for smaller operational databases, not for every SQL Server scenario. Architects who treat it as a drop-in replacement tend to find the gaps later, often mid-migration.
Where SQL Database Fits Inside the Microsoft Fabric Platform Fabric organizes work into workloads. The lakehouse handles files and large-scale analytics, the warehouse handles relational analytics at scale, and SQL Database handles operational work. Each one shares the same storage layer and the same security model.
Because they share OneLake, a row written by an application is visible to Power BI within minutes. Meanwhile, that same row is governed by the same workspace roles and sensitivity labels as everything else in the workspace.
How Fabric SQL Database Extends Beyond Traditional Database Hosting A hosted database in the cloud gives you compute, storage, and backups. Fabric adds a second layer on top of that. The database participates in a shared analytics platform.
The mirrored copy in OneLake can feed a semantic model, a notebook, and an AI agent at once. By contrast, a traditional hosted database needs an export step for each consumer. That difference shapes both architecture and cost.
The Difference Between Operational Data and Analytical Data in Fabric Operational data changes constantly and serves an application. Analytical data changes in batches and serves reporting. Fabric keeps both in one platform, but the two still want different engines.
SQL Database serves the operational side. The warehouse and lakehouse serve the analytical side. Mixing the two jobs onto one engine is where most early adopters stumble.
Why Microsoft Introduced SQL Database as a Fabric Workload Microsoft added the workload because customers kept rebuilding the same bridge. Teams ran an application database, then copied its data into the warehouse for reporting. That copy step was slow, costly, and a common source of disagreement over which numbers were correct.
By putting the transactional engine inside Fabric, Microsoft collapsed the bridge into the platform. Therefore, a single workload can serve an app and its reporting without a separate pipeline.
Before you commit, run a quick relevance check on your workload.
Does the application need near-real-time analytics on its own data? Is the working set small enough to sit in a shared capacity? Can the code tolerate the compatibility gaps covered later in this guide? Is the reporting consumer already inside Fabric or Power BI? Would a separate pipeline be an unacceptable cost or delay? If most answers are yes, the workload is a reasonable candidate. If most are no, another engine will serve you better.
SQL Database in Microsoft Fabric Architecture: How the Engine Works Understanding the architecture explains the limits you will hit later. The engine is real Azure SQL, but the storage and the surrounding services follow Fabric rules. Those rules decide performance, availability, and cost.
SQL Database Engine and Fabric OneLake Integration The database engine handles transactions, locking, and query plans the way Azure SQL always has. Underneath, the tables are stored in OneLake as Delta tables. Microsoft documents this storage model in its SQL database in Fabric overview .
The engine writes to both its own storage and the mirrored Delta copy. As a result, readers on the analytics side see data that is close to real time. The lag is small, but it is not zero, and that matters for some workloads.
Automatic Data Availability for Analytics Workloads You do not build the analytics copy yourself. Fabric maintains it as tables change. For instance, an insert from an application appears in the Delta table without a scheduled job.
This automatic path is one-directional by design. Analytics reads the mirrored copy, and writes flow back through the database engine. Teams expecting two-way writes to the Delta files will be disappointed.
Relationship Between SQL Database, Lakehouse, Warehouse, and Power BI These four workloads form a chain. SQL Database holds live operational rows, the lakehouse and warehouse reshape them for analysis, and Power BI presents the result. Each step shares storage rather than copying it.
The semantic model in Power BI can read from the warehouse, the lakehouse, or the mirrored database tables. That flexibility lets you place the reporting layer where it performs best.
For a wider view of how these pieces connect, see this guide to Microsoft Fabric architecture .
Metadata, Security, and Governance Flow Across Fabric Metadata travels with the data. Column names, types, and sensitivity labels defined in the database appear in the mirrored tables. Therefore, governance does not restart at the analytics layer.
Security follows the same path. Workspace roles, item permissions, and Microsoft Purview policies apply across the platform. The Fabric overview describes this shared governance model.
Case Study
Revolutionizing Sales and Financials KPIs with Microsoft Fabric
See how one enterprise consolidated sales and financial reporting onto Microsoft Fabric and rebuilt its KPI layer on a single governed platform.
Read the Case Study → SQL Database in Fabric vs Azure SQL Database: What Changes Both products run the same engine, so the SQL surface feels familiar. The differences sit in deployment, management, and the surrounding platform. Those differences decide which one belongs in a given architecture.
Shared SQL Foundation and Key Capability Differences The query language, data types, and most built-in functions are common to both. However, Fabric’s version ships a narrower set of enterprise features and management surfaces. It focuses on the transactional core plus analytics integration.
Azure SQL Database carries the fuller feature set, including a long list of service tiers and configuration options. Fabric trades some of that breadth for tight integration with the rest of the platform.
Deployment Model and Infrastructure Management Differences In Fabric, you create the database as a workspace item. Therefore, there is no server to size, no elastic pool to tune, and no separate billing meter for the database. It draws from the workspace capacity instead.
Azure SQL Database gives you explicit control over compute tiers, vCores, and storage limits. For teams that need that control, the extra knobs are a feature rather than a burden.
Feature Gaps Enterprise Teams Need to Validate Several familiar capabilities are absent or reduced. For example, cross-database queries and some linked-server patterns do not work the same way. Teams that lean on those patterns must redesign before they migrate.
The gaps show up during integration testing rather than during schema creation. That is why a compatibility assessment belongs before the first table is moved, not after.
When Azure SQL Database Remains the Better Choice Azure SQL Database stays the right answer for high-volume transactional systems with strict latency targets. Similarly, it fits workloads that need the full enterprise feature set or independent scaling from other platform services.
If the application has no analytics consumer and no Fabric footprint, adding Fabric introduces cost without benefit. In that case, keep it where it is.
Capability SQL Database in Fabric Azure SQL Database Engine Azure SQL engine Azure SQL engine Storage OneLake Delta, mirrored Proprietary managed storage Billing Shared Fabric capacity Per-database or pool Analytics integration Native, automatic mirror External pipeline needed Feature breadth Transactional core Full enterprise set Scaling control Via workspace capacity Explicit tiers and vCores
SQL Database in Fabric vs Fabric Warehouse: Choosing the Right Engine This is the choice architects face most often inside Fabric. Both store relational data, but they are built for opposite jobs. Picking the wrong one shows up as slow reports or slow transactions.
Transaction Processing vs Analytical Processing SQL Database handles many small reads and writes at once. The warehouse handles a few large reads across millions of rows. Each engine plans queries and stores data to favor its own pattern.
A row-by-row insert runs quickly in the database and slowly in the warehouse. Conversely, a wide aggregation runs well in the warehouse and poorly in the database.
Data Modeling Differences Between SQL Database and Warehouse The database rewards a normalized model with primary keys, foreign keys, and narrow rows. The warehouse rewards a denormalized star schema with wide fact tables. Modeling for one engine and running it on the other wastes the platform.
Decide the model before the migration, not during it. Rebuilding a schema after go-live is far more expensive than choosing well up front.
Query Patterns Each Engine Handles Best Point lookups, short transactions, and indexed seeks are the database’s strength. Set-based aggregations, large joins, and scans are the warehouse’s strength. A workload that mixes both is a signal to split the work.
Keep the application on the database and push the reporting aggregate to the warehouse. That split keeps each engine on the job it was built for.
BI Reporting, Semantic Models, and Enterprise Analytics Fit Power BI can read from either engine, but the warehouse is the natural home for large semantic models. The database serves better as a source for near-real-time operational dashboards.
Small departmental reports can read the database directly and still perform well. Table size and query shape set the threshold.
Requirement SQL Database Fabric Warehouse Primary job Transactions Analytics Typical model Normalized, keyed Star schema, wide Best query Indexed seek Large aggregation Row writes Fast Slow, batch only BI fit Operational dashboards Large semantic models Wrong choice shows as Slow reports Slow transactions
SQL Database in Fabric vs Microsoft Fabric Lakehouse and Synapse Two more comparisons matter before a decision. The lakehouse SQL endpoint and the Synapse dedicated pools both handle analytics, but each has a different origin and a different cost shape.
Compared With Lakehouse SQL Endpoints The lakehouse SQL endpoint gives you read-only T-SQL over Delta files. It is excellent for exploration and light reporting. However, it is not a transactional engine and does not accept application writes.
SQL Database accepts writes and maintains the Delta copy for you. Therefore, use the endpoint to read and the database to run the application.
Compared With Dedicated SQL Pools in Synapse Synapse dedicated pools are built for very large analytical workloads. They support massive concurrency and huge data volumes, and they bill for provisioned compute whether or not you use it.
Fabric’s warehouse and database instead draw from shared capacity. Meanwhile, teams already invested in Synapse do not need to move at once; the two can coexist during a transition.
If you are weighing the two platforms directly, this comparison of Fabric versus Synapse covers the trade-offs in more depth.
Choosing Between Open Data Formats and Relational Storage Open formats keep your options wide. Delta files in OneLake can be read by Spark, Power BI, and other engines without a vendor lock. That openness is a real advantage for long-lived data assets.
Relational storage gives you strict typing, constraints, and transactional integrity. For an application that depends on those guarantees, the relational path is the safer one. Fabric’s database gives you both, with the Delta copy maintained automatically.
Migration Considerations From Synapse Analytics Moving from Synapse is rarely a lift and shift. Dedicated pool workloads assume a provisioning model that Fabric does not use. As a result, the migration rewrites the workload for a new platform.
Validate concurrency, distribution strategy, and cost before you commit. A pilot on one reporting domain will reveal more than a full migration plan on paper.
Platform Best Fit Limitations SQL Database in Fabric Operational apps plus reporting Smaller scale, feature gaps Fabric Warehouse Relational analytics at scale No row-level transactional writes Lakehouse SQL endpoint Exploration and light reporting Read-only over Delta Synapse dedicated pool Very large analytical workloads Provisioned cost, separate platform
SQL Database in Microsoft Fabric T-SQL Compatibility and Limitations Compatibility decides whether a migration is a weekend job or a quarter-long project. The engine supports most common T-SQL, but the exceptions matter more than the common cases. Find them early.
Supported T-SQL Capabilities Teams Can Reuse Core DDL and DML work as expected. Tables, views, indexes, stored procedures, functions, and triggers all exist, and the query optimizer behaves like Azure SQL. For most applications, the day-to-day surface is unchanged.
Common security constructs such as roles, users, and permissions carry over. Teams can bring their existing schema scripts with minor edits.
Compatibility Gaps From Traditional SQL Server Environments The gaps cluster in a few areas. Cross-database queries, some linked-server patterns, and certain SQL Server Agent features do not behave the same way. Full-text and some advanced indexing options are also reduced.
Microsoft publishes the current limits in its SQL database limitations page . In practice, teams should treat that page as the source of truth for their compatibility check.
Stored Procedures, Functions, and Database Objects Considerations Stored procedures and functions migrate well in most cases. However, procedures that depend on cross-database reads or on unsupported system objects need rewriting. Those are the ones that break integration tests.
A procedure that joins across two databases must be redesigned to read from one. That redesign is small in isolation and large across hundreds of objects.
Application Migration Risks Before Moving Existing Workloads The risk is rarely the language and often the assumptions around it. Connection strings, retry logic, and transaction scope all need review. Therefore, test the running application as well as the schema.
A short pilot against a representative workload will surface most of these issues. Budget for the rewrite of any object that fails the assessment.
Inventory every cross-database and linked-server reference in the codebase. List stored procedures and jobs that rely on SQL Server Agent. Flag unsupported indexing and full-text features in use. Check connection strings and retry logic for assumptions about the server. Confirm transaction scope behaves as the application expects. Run a pilot on one representative workload before committing the rest. Enterprise Workload Patterns That Fit SQL Database in Fabric Some workloads fit the engine naturally. The common thread is a modest data size paired with a real need for reporting or AI access. When those two conditions hold, the workload tends to succeed.
Operational Applications Requiring Analytics Integration Applications that need their own data reflected in dashboards are the clearest fit. A service desk, an inventory tool, or a field app all benefit from the automatic mirror. There is no separate pipeline to build or maintain.
The reporting team stops waiting on nightly extracts. The data they see is close to what the application just wrote.
Department-Level Applications and Line-of-Business Systems Departmental systems rarely reach the scale where the engine struggles. Their working sets are small, their concurrency is modest, and their reporting needs are real. This is the sweet spot for the workload.
Central IT gains governance over data that used to live in scattered local databases. That consolidation is often the strongest argument for adoption.
AI Applications Requiring Current Operational Data AI features need fresh data to stay useful. A retrieval agent that reads yesterday’s snapshot gives stale answers. When the database mirrors to OneLake, an agent can query data that is only minutes old.
A support assistant can pull the current state of a ticket rather than a nightly copy. That freshness is hard to achieve with a traditional warehouse pipeline.
Lightweight Application Databases Inside Fabric Projects Small databases that support a Fabric project itself fit well. A configuration store, a metadata catalog, or a staging database all work here. They stay close to the analytics that consume them.
Keep these databases small and purpose-built. They support the main system of record.
Workload Fit Level Reason Operational app with dashboards High Automatic mirror removes a pipeline Departmental line-of-business system High Small scale, real reporting need AI feature needing fresh data High Near-real-time OneLake copy Supporting project database Medium Convenient, but not a system of record High-volume OLTP system Low Scale and SLA limits
Workloads That Should Not Use SQL Database in Fabric Honest guidance includes the cases where the answer is no. Several workload classes are poor fits, and forcing them onto the engine creates cost and risk. Recognizing them early saves a failed migration.
High-Volume Transactional Systems With Strict SLAs Systems that push thousands of transactions per second need dedicated compute and predictable latency. A shared capacity model does not guarantee that. Therefore, keep these on Azure SQL Database or another dedicated engine.
The mirror also adds a small write overhead. At high volume, that overhead compounds into a real cost.
Large Enterprise Data Warehouses A warehouse with billions of rows belongs in the warehouse workload, not the database. The engine is not built for that volume of analytical scans. Placing it there produces slow queries and unhappy users.
The Fabric Warehouse is designed for exactly that job. Use the right tool for the analytical load.
Complex Analytical Processing at Massive Scale Heavy transformations, large joins, and wide aggregations strain the transactional engine. Meanwhile, Spark and the warehouse handle those jobs far better. Keep the compute-intensive work off the database.
Systems Requiring Advanced SQL Server Enterprise Features If a workload depends on features the Fabric engine does not support, the decision is made for you. Cross-database transactions, certain high-availability options, and advanced tuning features are the usual blockers. Verify each one against the limitations page.
The system needs sustained thousands of transactions per second. Latency targets are strict and must not vary with shared capacity. The data volume belongs to a warehouse, not a database. Analytical scans run against billions of rows. The workload depends on unsupported enterprise features. There is no analytics consumer and no Fabric footprint. Performance, Scaling, and Cost Behaviour at Enterprise Scale Performance in Fabric is a shared-resource story. The database competes with the lakehouse, the warehouse, and every other item in the capacity. Understanding that competition is the key to predictable results.
How Fabric Capacity Impacts SQL Database Performance Fabric capacity is a pool of compute units shared across a workspace. When one workload spikes, others can slow down. As a result, a heavy report can briefly affect application response time.
Microsoft explains the licensing and capacity model in its Fabric licensing documentation . Architects should model peak concurrency across every item in the capacity.
Understanding Compute Consumption and Workload Isolation Workload isolation exists, though it is limited. You can separate items across capacities to reduce interference, at the cost of more capacity. For a mixed estate, that separation is often worth the spend.
Teams place the busiest transactional database in its own capacity. Meanwhile, reporting items share a second capacity. That split keeps the two from fighting.
Query Performance Considerations for Large Tables Large tables in the database hurt both the transaction path and the mirror. Indexing helps reads but adds write overhead. Therefore, keep tables lean and archive old rows on a schedule.
A table that grows without pruning will slow over time even under steady load. Plan retention from the start.
Cost Factors Architects Should Model Before Adoption Capacity pricing changes how cost behaves. You pay for the pool, not per database, so an idle database still consumes shared capacity. That difference surprises teams used to per-database billing.
Model peak usage, not average usage, and add headroom for growth. The SQL analytics endpoint docs help clarify how reads against mirrored data are charged.
Cost Driver SQL DB in Fabric Azure SQL Fabric Warehouse Synapse Pool Billing basis Shared capacity Per database Shared capacity Provisioned compute Idle cost Still consumes pool Tier dependent Still consumes pool Billed when idle Scaling Capacity-wide Independent Capacity-wide Manual Noisy neighbour risk Present Low Present Low Model for Peak concurrency Sustained load Peak concurrency Provisioned size
Watch on YouTube
Why Most Fabric Deployments Fail at Scale
Amit Chandak, Microsoft MVP, on the deployment and capacity decisions that quietly cap a Fabric rollout once real workloads land.
Data Modeling and Query Design Recommendations for Fabric SQL Database Good modeling makes the difference between a fast database and a slow one. The rules are familiar from SQL Server, with a few adjustments for the mirrored copy. Apply them from the first table.
Relational Modeling Patterns That Work Well Normalize to the point where integrity is clear, and no further. Use primary keys, foreign keys, and appropriate data types. Narrow rows and stable keys keep both the transaction path and the mirror efficient.
Avoid over-indexing. Every index adds write overhead, and write overhead slows the mirror.
Avoiding Traditional OLTP Design Mistakes Some habits from on-premise SQL Server do not carry over. Very wide tables, unbounded growth, and heavy triggers all cause problems here. Therefore, review those patterns before you migrate.
A trigger that updates several tables on every insert multiplies write cost. Consider moving that logic to the application layer.
Preparing Data for Analytics Consumption The mirrored tables are read by analytics engines, so their shape matters. Use clear column names and consistent types. Denormalize at the analytics layer rather than in the operational tables.
Keep timestamps in a consistent zone and store currency values with their codes. Small choices here save large cleanup later.
Designing Tables for Power BI and AI Workloads Power BI favors star schemas with clean relationships, so build a semantic layer over the mirrored data. AI workloads favor well-labeled, consistent rows. Both benefit from the same discipline at the source.
Design the operational schema with its downstream readers in mind. It costs little now and saves rework once reports are live.
Checklist
Microsoft Fabric Readiness Before You Build
A practical checklist for the decisions that come before a workload moves into Fabric: capacity, governance, security, and compatibility.
Get the Checklist → Security, Governance, and Compliance Considerations Because operational and analytical data share a platform, governance has more surface area here. The same policies must cover both the application rows and the mirrored copies. Getting this right is a design task.
Identity Management With Microsoft Entra ID Identity flows through Microsoft Entra ID for the whole platform. Users and applications authenticate once and receive permissions per item. There is no separate identity store for the database.
Joiner, mover, and leaver processes cover the database automatically. That consistency reduces the risk of orphaned access.
Role-Based Access Control and Data Permissions Access is governed by workspace roles and item permissions. Within the database, SQL roles and users still apply. The two layers work together, and both must be configured deliberately.
A user with workspace read access still needs the right SQL permissions to query the database. Test both layers before go-live.
Microsoft Purview Integration for Governance Purview brings sensitivity labels, classification, and lineage to the platform. Labels applied to the database columns flow into the mirrored tables. Therefore, protection follows the data into analytics.
Kanerika has been an early implementor of Purview, which helps when the governance requirement is strict. The integration is strongest when labels are applied at the source.
Lineage, Auditing, and Compliance Requirements Lineage shows where data came from and where it went. Auditing records who accessed what and when. Both matter for regulated workloads, and both are available across the platform.
Coverage depends on configuration. Plan the audit scope and retention before production, not after an examiner asks.
Confirm every database item inherits a sensitivity label strategy. Map workspace roles to SQL roles and test both together. Decide audit scope and retention before production. Validate lineage coverage from source through the mirror. Review joiner, mover, and leaver flows for database access. Document who owns each dataset and each policy. Migration Strategies for Moving Existing SQL Workloads to Fabric Migration succeeds when teams treat it as a re-platform exercise. The engine is compatible enough to move fast and different enough to demand care. A staged approach manages both.
Assessing SQL Server and Azure SQL Database Workloads Start with a full inventory. Record schema size, transaction volume, concurrency, and every external dependency. That picture tells you which workloads are candidates and which are not.
Score each workload against the fit criteria covered earlier. A simple high, medium, low rating is enough to sequence the work.
Refactoring Applications for Fabric Compatibility Refactoring focuses on the gaps. Rewrite cross-database queries, replace unsupported features, and adjust connection handling. For example, a procedure that read from two databases must be pointed at one.
Refactor behind a test suite so each change is verified. Silent behavior changes are the enemy of a safe migration.
Moving Data and Validating Performance Move the schema, then the data, then the application. Validate row counts, key relationships, and query plans at each step. Load tests should mirror real concurrency, not a friendly average.
The load test is where shared-capacity behavior shows itself. Tune capacity before go-live.
Avoiding Lift-and-Shift Migration Problems A pure lift and shift carries old design decisions into a new engine. That rarely ends well. Instead, revisit the schema and the code while you move them.
Use a decision framework to place each workload deliberately.
Move workloads that fit and need analytics integration now. Modernize workloads that fit after targeted refactoring. Replatform workloads that belong in the warehouse or lakehouse. Retain workloads that need enterprise features or dedicated compute. Reassess every retained workload at the next planning cycle. Migration ROI Calculator
Estimate Your Fabric Migration Return
Model migration effort, timeline, and cost savings before you commit to a move from SQL Server or Azure SQL into Fabric.
Calculate Migration ROI → Implementation Blueprint for Enterprise Adoption A repeatable blueprint keeps a large adoption from drifting. The four phases below move from assessment to production in a controlled way. Each phase ends with a clear checkpoint.
Phase 1: Workload Assessment and Architecture Design Inventory workloads and score them against the fit criteria. Design the target architecture, including capacity placement and workload isolation. This phase produces the plan the rest of the work follows.
Phase 2: Schema Migration and Data Integration Move schemas and data into the new databases. Build or adjust integration points and confirm the mirror behaves as expected. Validate counts and relationships before moving on.
Phase 3: Security, Governance, and Testing Apply identity, roles, labels, and audit settings. Run functional and performance tests against realistic load. This phase is where most hidden gaps surface, so give it room.
Phase 4: Production Rollout and Optimization Cut over in stages and watch capacity closely. Tune indexes, retention, and capacity as real usage appears. Optimization continues after go-live rather than ending with it.
Real Enterprise Architecture Patterns Using SQL Database in Fabric Patterns help architects see how the pieces combine in practice. The four below cover the most common shapes, from a simple reporting chain to a full multi-workload platform.
SQL Database Plus Warehouse Plus Power BI Pattern An application writes to SQL Database, and the warehouse reshapes the mirrored data. Power BI reads from the warehouse for large models and from the database for operational views. This is the most common starting pattern.
SQL Database Plus Lakehouse Plus AI Agent Pattern An AI agent reads current operational data through the lakehouse layer. The mirror keeps the agent’s context fresh without a separate pipeline. Meanwhile, the lakehouse handles the heavier feature engineering.
Hybrid Azure SQL and Fabric Architecture Some workloads stay on Azure SQL Database while reporting moves to Fabric. A pipeline keeps the analytical copy current. This hybrid shape fits teams that cannot move the transaction engine yet.
Multi-Workload Fabric Data Platform Pattern Larger estates combine several workloads across capacities. Operational databases sit in one capacity, analytics in another, and governance spans both. This pattern trades more capacity for cleaner isolation.
How Kanerika Helps Enterprises Evaluate and Implement Fabric SQL Database Kanerika is a Microsoft Solutions Partner for Data and AI with the Analytics Specialization, and a Microsoft Fabric Featured Partner. The firm also holds the Microsoft Advanced Specialization for Data Warehouse Migration to Microsoft Azure. That combination is relevant when a Fabric decision spans both analytics and migration.
Governance and delivery credentials matter for enterprise work. Kanerika holds ISO 27001, ISO 27701, and ISO 9001 certifications, SOC II Type II compliance, and a CMMI Level 3 appraisal. The firm was also named a Major Contender in the Everest Group Microsoft Azure Services PEAK Matrix Assessment 2026.
Fabric Architecture Assessment Kanerika starts with a workload assessment. The team inventories existing databases, scores them against the fit criteria, and recommends where each one belongs. The output is a target architecture the team can build against.
SQL Workload Modernization and Migration Planning For migration, Kanerika uses FLIP, its DataOps platform, with an Azure to Fabric Migration Accelerator. The accelerator is reported to deliver 80% faster migration timelines, 50% lower costs, and 65% fewer resources required. It is available as a native Fabric workload from any workspace.
Data Governance and Security Implementation Kanerika implements governance on Microsoft Purview, where it was one of the earliest implementors globally. The kanSuite services cover governance strategy, compliance frameworks, and access protection. These are services delivered on Purview, not a licensed product.
Fabric Optimization and Production Support After go-live, Kanerika tunes capacity, indexing, and retention against real usage. Karl, the firm’s AI data insights agent, is reported to cut analysis time by 65% for teams that adopt it. Ongoing support keeps the platform aligned with changing workloads.
A Microsoft Customer Story That Names Kanerika One published example shows the pattern in production. FoodPharma unified six operational systems on Microsoft Fabric with Kanerika as the delivery partner. The project consolidated 50+ tables and about one terabyte of historical data.
Reporting that once took two business days now completes in about 90 minutes. The BI team recovered roughly 15 hours per week of manual data work, and the implementation ran in seven weeks. This is a Microsoft customer story, published and third-party verified.
For teams weighing a Fabric migration, the Azure to Fabric migration service page describes the accelerator path in more detail.
Kanerika Service
Data Architecture for Microsoft Fabric
Kanerika designs workload placement, governance, and migration paths for Fabric estates, from the first assessment through production rollout.
Explore Data Architecture → Wrapping Up SQL Database in Microsoft Fabric is a strong fit for operational workloads that need reporting or AI access close by. It is a poor fit for high-volume transaction systems and giant warehouses. The decision rests on workload placement, not on feature checklists alone. Assess compatibility, model capacity cost against peak usage, and pilot one workload before committing the rest. Teams that place each database deliberately will get the integration benefit without inheriting a system the engine was never built to run.
Frequently Asked Questions
Is SQL Database in Microsoft Fabric replacing Azure SQL Database? No. Azure SQL Database remains Microsoft’s fully managed PaaS database and continues to receive new capabilities. SQL Database in Microsoft Fabric is a separate engine that hosts the same SQL database engine inside a Fabric workspace, so teams can run transactional databases and analytics in one platform. Enterprises running mission-critical Azure SQL workloads should not treat the Fabric option as a replacement; the decision is workload placement, not product lifecycle. Kanerika’s Fabric workload assessments help architects map which databases belong where.
What is the difference between SQL Database in Fabric and Fabric Warehouse? SQL Database in Fabric runs an operational, transactional engine optimized for OLTP workloads with row-level writes and ACID transactions. Fabric Warehouse is a distributed analytics engine optimized for large aggregations and columnar storage; it does not support row-level transactional writes. In practice, teams use SQL Database to run operational applications and reporting at the source, and the Warehouse for enterprise-scale relational analytics. Choosing between them is a workload-placement decision, which the comparison section of this guide walks through in detail.
Can existing SQL Server applications run on SQL Database in Fabric? Most applications that connect through the standard TDS endpoint work with minimal changes, because SQL Database in Fabric exposes a SQL Server-compatible connection string and supports common client drivers. Applications do need refactoring where they depend on features Fabric does not offer, such as certain SQL Server Agent capabilities or unsupported instance-level features. A compatibility assessment before migration catches these gaps early and prevents a lift-and-shift from turning into a blocked migration.
Does SQL Database in Fabric support full T-SQL compatibility? It offers broad T-SQL surface-area support for the operations transactional applications rely on, but it is not 100% identical to SQL Server. Some instance-level features, specific system objects, and advanced Enterprise Edition capabilities have gaps or behave differently. Teams should run their actual schema, stored procedures, and queries through a compatibility check rather than assuming parity. The T-SQL section of this guide lists the limitation categories that most often become migration blockers.
When should enterprises choose SQL Database instead of Lakehouse or Warehouse in Fabric? Choose SQL Database when the workload is transactional: line-of-business applications, order and inventory systems, and systems that need frequent row-level inserts and updates with strict SLAs. Choose Warehouse for heavy relational analytics and Lakehouse for exploration and reporting over Delta files in a medallion architecture. When one platform serves operational writes plus downstream analytics, SQL Database paired with automatic replication into OneLake removes the hand-built ETL that separate engines used to require.
How does SQL Database in Fabric handle enterprise-scale workloads? Scale is consumed through Fabric capacity units rather than a fixed database tier, so compute grows with the capacity you assign to the workspace. Workload isolation, result-set caching, and the mirroring of data into OneLake for analytics keep operational load and analytical query power separate. Very high-volume transactional systems with strict SLAs should still be benchmarked first, since capacity throttling behavior differs from a dedicated Azure SQL tier. Kanerika benchmarks candidate workloads before recommending placement.
What are the limitations of SQL Database in Microsoft Fabric? The main categories are: a reduced T-SQL surface compared with SQL Server Enterprise features, capacity-based consumption instead of a fixed performance tier, and feature gaps in areas like advanced security options and SQL Server Agent scheduling that some applications assume. There are also storage and database-size limits tied to capacity SKU. None of these are hidden, and Microsoft publishes them, but they belong in the assessment before migration rather than in production.
How does SQL Database in Fabric work with Power BI and AI workloads? Because SQL Database in Fabric replicates its data into OneLake automatically, Power BI semantic models and Copilot experiences can query near-real-time copies without extracting or copying data anywhere. Shortcuts let analytics engines read the replicated data directly, and AI agents can serve grounded answers from the same governed copy. This single-copy architecture is the core reason enterprises pair an operational fabric database with analytics instead of staging a separate warehouse feed.
What is the difference between Fabric warehouse and Fabric SQL database? Fabric Warehouse is optimized for large-scale analytical workloads using distributed query processing, while Fabric SQL Database is designed for operational and transactional workloads requiring ACID compliance. The warehouse excels at complex aggregations across massive datasets, whereas SQL Database in Microsoft Fabric supports OLTP patterns with row-level operations and real-time data modifications. Warehouse uses columnar storage for analytics; SQL Database uses traditional relational structures. Kanerika helps enterprises choose the right Fabric workload for their specific data architecture needs, connect with our team for a tailored assessment.
Does Microsoft Fabric have a database? Yes, Microsoft Fabric includes SQL Database as a native workload within its unified analytics platform. This fully managed relational database brings the SQL Server engine directly into Fabric, enabling transactional data storage alongside analytics, data engineering , and business intelligence capabilities. SQL Database in Fabric eliminates the need for separate database infrastructure while maintaining compatibility with existing SQL Server tools and T-SQL syntax. Kanerika’s Microsoft Fabric specialists can help you integrate SQL Database into your existing data estate, reach out to explore your options.
How does SQL Database in Fabric handle data replication? SQL Database in Fabric automatically replicates data to OneLake through built-in mirroring, creating analytics-ready Delta Parquet files without manual configuration. This near real-time replication enables immediate querying through SQL analytics endpoints and Spark notebooks. Changes in the transactional database propagate automatically, eliminating traditional ETL processes for analytical workloads. The mirrored data maintains consistency while optimizing storage formats for analytical query patterns. Kanerika architects data replication strategies that use Fabric’s native capabilities for smooth operational-to-analytical data flows, schedule a technical deep-dive with our team.
What is the capacity of SQL database in Fabric? SQL Database in Fabric capacity scales based on your Fabric SKU allocation, with compute resources measured in Capacity Units. Storage scales independently up to 4TB per database in standard configurations. Performance scales automatically based on workload demands within allocated capacity, using intelligent resource management. Higher Fabric SKUs provide more concurrent connections and faster query processing. Capacity consumption follows Fabric’s unified billing model, simplifying cost management across all platform workloads. Kanerika performs capacity planning assessments to right-size your Fabric SQL Database deployment, request a sizing consultation to optimize costs.
Does Microsoft Fabric include SQL Server? Microsoft Fabric does not include a full SQL Server installation but incorporates the SQL Server database engine within its SQL Database workload. You get SQL Server capabilities including T-SQL compatibility, stored procedures, and familiar management interfaces without managing server infrastructure. However, features like SQL Server Agent, linked servers, and certain extended stored procedures are not available. Fabric provides a managed, cloud-native experience rather than traditional server deployment. Kanerika helps organizations transition SQL Server workloads to Fabric SQL Database appropriately, consult with us to evaluate feature compatibility.
How to connect Fabric to SQL? Connecting to SQL Database in Fabric uses standard SQL Server connection methods. Retrieve your connection string from the database settings in your Fabric workspace, then connect using SQL Server Management Studio, Azure Data Studio, or any ODBC/JDBC-compatible application. Authentication supports Azure Active Directory and SQL authentication depending on configuration. For programmatic access, use Microsoft.Data.SqlClient or pyodbc libraries with your Fabric SQL endpoint. Connection strings follow standard SQL Server format with your Fabric-specific server name. Kanerika develops integration solutions connecting enterprise applications to Fabric SQL databases, let us architect your connectivity layer.
How to enable SQL database in Fabric? Enabling SQL Database in Fabric requires Fabric capacity administrator access and appropriate SKU provisioning. Navigate to the Fabric admin portal, ensure your capacity supports SQL Database workloads, and verify tenant settings allow database creation. Workspace administrators can then create SQL databases within enabled workspaces. Some organizations may need to enable the feature through tenant settings if disabled by default. Ensure your Fabric license tier includes SQL Database capabilities before attempting enablement. Kanerika assists organizations with Fabric tenant configuration and SQL Database enablement, contact us for setup guidance.
What version of SQL is a Fabric data warehouse? Fabric Data Warehouse uses a proprietary distributed SQL engine optimized for analytical workloads, not a specific SQL Server version. It supports T-SQL syntax compatible with SQL Server 2022 standards but runs on architecture designed for columnar storage and massively parallel processing. The engine handles analytical patterns differently from transactional SQL Server, optimizing for aggregations and joins across large datasets. Some T-SQL features unavailable in traditional warehouses may not be supported. Kanerika evaluates T-SQL compatibility during warehouse migration planning, engage our team for a thorough code compatibility assessment.
Is Fabric an alternative to Databricks? Microsoft Fabric competes directly with Databricks as a unified analytics platform, though each has distinct strengths. Fabric offers tighter Microsoft platform integration, simplified licensing, and native Power BI connectivity. Databricks excels in advanced machine learning workflows, open-source flexibility, and multi-cloud deployment options. Organizations heavily invested in Microsoft technologies often find Fabric more natural, while data science-focused teams may prefer Databricks’ MLflow integration. Both platforms support lakehouse architecture and SQL analytics. Kanerika implements both platforms and helps enterprises select the right fit, schedule a platform comparison consultation.
How to query Microsoft Fabric? Querying Microsoft Fabric depends on your target workload. For SQL Database, use T-SQL through SSMS, Azure Data Studio, or the Fabric web editor. Warehouse queries use similar T-SQL syntax through SQL analytics endpoints. Lakehouse data supports both Spark SQL in notebooks and T-SQL through automatically generated SQL endpoints. Power BI connects directly for visual querying, while REST APIs enable programmatic data access. All queries read through OneLake’s unified storage layer regardless of interface choice. Kanerika develops optimized query patterns across Fabric workloads, engage our data engineers to improve your query performance.
Which technique is recommended to optimize SQL queries in Microsoft Fabric? Optimizing SQL queries in Microsoft Fabric starts with proper indexing strategies in SQL Database and appropriate data distribution in Warehouse. Use query execution plans to identify bottlenecks, use result set caching for repeated queries, and minimize data scanning through selective column projection. Partition large tables by frequently filtered columns and use statistics updates to maintain query optimizer accuracy. For warehouse workloads, structure queries to maximize parallelism and minimize data movement across nodes. Kanerika’s performance tuning experts optimize Fabric SQL workloads for enterprise-scale efficiency, request a query performance review.
How to create a SQL database in Microsoft Fabric? Creating a SQL database in Microsoft Fabric requires navigating to your Fabric workspace, selecting New Item, and choosing SQL Database from the available options. You’ll configure the database name, select your capacity, and define initial settings. Once provisioned, you can immediately connect using SQL Server Management Studio, Azure Data Studio, or the built-in Fabric query editor. The database automatically inherits workspace security and governance policies. Kanerika accelerates Fabric SQL database deployment with proven implementation frameworks, schedule a consultation to simplify your setup.
Does Fabric replace SQL Server? Microsoft Fabric does not replace SQL Server but complements it within modern data architectures. SQL Server remains essential for on-premises deployments, complex transactional applications, and scenarios requiring full database engine control. Fabric SQL Database offers a managed alternative for cloud-native workloads integrated with analytics capabilities. Organizations typically run both, using SQL Server for mission-critical OLTP and Fabric for unified analytics and operational data platforms. Kanerika designs hybrid architectures that optimize both SQL Server and Microsoft Fabric investments, let us evaluate your modernization roadmap.
What is the difference between Azure SQL and Fabric? Azure SQL is a standalone managed database service focused purely on relational data storage and transactional processing. Microsoft Fabric is a full analytics platform that includes SQL Database as one workload among many, including data engineering, warehousing, and business intelligence. Azure SQL offers more granular database configuration options, while Fabric SQL Database prioritizes tight integration with analytics pipelines and OneLake storage. Choose Azure SQL for isolated database needs; choose Fabric for unified data platform strategies. Kanerika guides enterprises through Azure-to-Fabric migrations with minimal disruption, contact us for a migration assessment.
What are the benefits of using SQL Database in Fabric? SQL Database in Fabric delivers automatic replication to OneLake, enabling real-time analytics on transactional data without ETL pipelines. Benefits include unified governance through Microsoft Purview integration, simplified licensing under Fabric capacity, and native connectivity to Power BI for instant reporting. Developers gain autonomous database management with automatic scaling and built-in high availability. The integration eliminates data silos by keeping operational and analytical data within a single platform architecture. Kanerika helps enterprises realize these benefits through a planned Fabric SQL Database implementations, discuss your use case with our solutions team.
How secure is SQL Database in Fabric? SQL Database in Fabric inherits enterprise-grade security from both SQL Server and Microsoft Fabric platforms. Security features include row-level security, dynamic data masking, transparent data encryption at rest, and encryption in transit. Fabric’s unified security model applies workspace-level permissions, while integration with Microsoft Purview enables data classification and sensitivity labeling. Azure Active Directory authentication provides identity management, and private endpoints support network isolation requirements. Kanerika configures end-to-end security frameworks for Fabric SQL Database deployments, engage our security specialists to ensure compliance readiness.
Is Fabric SQL database in GA? SQL Database in Microsoft Fabric reached general availability in late 2024, moving beyond preview status to production-ready deployment. GA status means Microsoft provides full support, SLA guarantees, and committed feature stability for enterprise workloads. Organizations can now confidently deploy SQL Database in Fabric for mission-critical transactional applications with production support agreements. Check Microsoft’s Fabric documentation for the latest feature releases and regional availability updates. Kanerika stays current with Fabric releases to guide production deployments, connect with us to plan your GA implementation strategy.
