TL;DR
A T-SQL notebook in Microsoft Fabric lets you write SQL and see the results in the same document. It queries a Fabric Warehouse, and it can read a Lakehouse without changing it. Microsoft made it generally available in June 2025, so it is no longer a preview. Each cell you run gets its own connection, so nothing carries over to the next cell. One query can read several warehouses at once if they share a workspace. Any result can be saved as a new table or a view. You can put a notebook on a schedule, but a scheduled run cannot take a parameter.
Key Takeaways T-SQL notebooks have been generally available since June 2025, so any guide still calling them a public preview is describing a version of Fabric that no longer exists. Every code cell opens its own SQL session, so a variable or a #temp table created in one cell is gone by the next one. Fabric Data Warehouse supports identity columns, and primary, foreign and unique keys exist as long as you declare them NOT ENFORCED. Three-part names give you cross-warehouse joins inside one workspace, but connections across regions are not supported at all. You can schedule a T-SQL notebook three different ways, and none of them can pass a parameter into it or run it as a service principal. A T-SQL notebook and the %%tsql magic in a Python notebook are two different features at two different maturity levels, and they reach different targets. Watch on YouTube
How Microsoft Fabric Helps Reduce Cost and Boost Data Performance
A walkthrough of what actually moves warehouse query performance and capacity cost in a real Fabric deployment, which is the context every T-SQL notebook runs inside.
The Query Nobody Could Reproduce Microsoft reported over 40,000 paid Fabric customers, up more than 60% year over year , on its FY26 Q4 earnings call in July 2026. A large share of those tenants arrived with a SQL Server or Synapse heritage. That means a lot of analysts arrived already fluent in T-SQL , and immediately asked where their query window went.
The answer turned out to be more interesting than a query window. A Fabric notebook holds the query, the explanation of why the query looks like that, and the result, in one saved artifact that a colleague can open six months later. The SQL script that produced last quarter’s reconciliation number stops being a file on somebody’s laptop.
That is the promise. The practical reality has some sharp edges, and most of what was written about them in 2025 is now wrong.
What a SQL Notebook Is, and Why SQL Teams Started Using One A SQL notebook is a document made of cells. Some cells hold SQL, some hold prose written in markdown, and the output of each query appears directly under the code that produced it. You run cells one at a time or all at once, and the whole thing saves as a single file.
Compare that to a query editor. A query editor holds one script, prints results to a grid, and forgets everything the moment you close the tab. The reasoning behind the query lives in a Slack thread, a ticket comment, or nowhere.
The format came out of the data science world, where Jupyter made the pattern familiar, and it spread into SQL tooling from there. Visual Studio Code has SQL notebooks in its MSSQL extension , and most cloud analytics platforms now ship some version of the idea.
For a SQL team the real draw is reviewability. A validation routine written as a notebook can be read by an auditor, handed to a new analyst, or attached to a change request, because the intent sits next to the code.
The trade-off is scope. A notebook works as a development and analysis surface. Teams that treat every one as a deployable production asset end up with notebook sprawl , a governance problem we come back to further down.
What a T-SQL Notebook Is in Microsoft Fabric Microsoft’s own documentation page is titled T-SQL support in Microsoft Fabric notebooks , and the wording matters. This is not a separate item type sitting beside the Fabric notebook. It is the standard Fabric notebook with T-SQL set as its language and a warehouse attached as its data source.
Microsoft’s description is direct. The feature “allows direct execution of T-SQL on connected warehouse or SQL analytics endpoint”. Most existing notebook capabilities carry over too, including charting results, co-authoring, scheduled runs and execution from a Data Integration pipeline.
The single most important fact about it is one the older write-ups all missed. T-SQL notebooks reached general availability in June 2025 . Microsoft’s own Fabric what’s-new archive records it as “The T-SQL notebook feature is now generally available.” Anything still calling it a public preview is describing a build more than a year old.
A T-SQL notebook reads through the Warehouse or the Lakehouse SQL analytics endpoint, never OneLake directly. Where It Sits Next to the Warehouse, the Lakehouse and OneLake A T-SQL notebook does not store data. It connects to something that does, and there are exactly two supported targets.
The first is a Fabric Data Warehouse , where you have the full read and write surface. Creating, altering and dropping tables, plus insert, update and delete, all work there.
The second is the SQL analytics endpoint of a Fabric Lakehouse , which Microsoft describes as a read-only T-SQL query surface over the Delta tables in OneLake. You can still create views, functions and stored procedures on top of it, but you cannot write to the underlying tables.
Both live in OneLake , which is why a single query can read from both. A mirrored database joins the same way through its own SQL analytics endpoint.
One thing the native notebook does not list as a data source is a Fabric SQL database . That target is reachable, but through a different route covered in the next section.
Three Ways to Run T-SQL in Fabric, and When Each One Wins This is where most guidance stops being useful, because it describes one route and ignores the other two. Fabric now gives you three places to type Transact-SQL, and they are at three different maturity levels.
The native T-SQL notebook is the generally available option and the one this article is mostly about. You attach warehouses, set one as primary, and every cell runs T-SQL against it.
The second route is the %%tsql magic command inside a Python notebook, documented on its own Microsoft Learn page . This is still in preview. It takes a -type argument, so a cell can point at a Warehouse, a Fabric SQL database or a lakehouse SQL analytics endpoint. It can also bind the result straight into a Python variable for pandas work.
The third is %%sql in a Spark notebook, which is Spark SQL rather than T-SQL. It reads and writes Delta tables in the lakehouse directly and follows Spark semantics, so it belongs to a different job entirely.
Execution surface Status What it can reach Write access Use it when Native T-SQL notebook Generally available since June 2025 Warehouse, Lakehouse SQL analytics endpoint Full DDL and DML on a Warehouse, read-only on the endpoint The work is SQL from start to finish and lives in the warehouse %%tsql in a Python notebookPreview Warehouse, Fabric SQL database, Lakehouse SQL analytics endpoint Full DDL and DML on a Warehouse or SQL database, read-only on the endpoint You need Python around the SQL, or you need to hit a Fabric SQL database %%sql in a Spark notebookGenerally available Lakehouse Delta tables Full read and write on Delta The workload is a large Spark transformation, not warehouse analytics
Table 1. The three places you can write SQL in Microsoft Fabric, and what each one actually reaches. The practical rule is simpler than the table. If the job never leaves SQL, use the native notebook, because it is the mature option. If SQL is one step inside a Python workflow, or the target is a Fabric SQL database, use %%tsql and accept that you are on a preview feature. If you are moving hundreds of millions of rows through transformations, you wanted a PySpark notebook all along.
How to Create a T-SQL Notebook and Attach a Warehouse There are two documented entry points, and most write-ups only mention one.
From a Fabric workspace , select New item and choose Notebook from the panel. From an existing warehouse editor, open the warehouse, then pick New SQL query and New T-SQL query notebook from the top ribbon. The second route is faster when you already know which warehouse you are working against, because it arrives pre-attached.
Once the notebook exists, T-SQL is already the default language. You then add data sources with the + Data sources button and the Warehouses option, picking items from the data hub panel .
Set a Primary Warehouse Before You Run Anything You can attach several warehouses and endpoints to one notebook, and one of them is designated primary. The primary warehouse is what runs the T-SQL, and any command that does not specify a three-part name resolves against it.
Getting this wrong produces a confusing failure. A CREATE TABLE you expected in the analytics warehouse quietly lands in whichever item happens to be primary. The error you eventually see is a missing object somewhere else entirely.
One constraint worth knowing before you start. You can only add warehouses and SQL analytics endpoints from the current workspace, so a notebook cannot reach across workspaces the way a pipeline can.
Setting the primary warehouse is the step teams skip, and the one that produces the strangest errors later. Running Cells, and the Session Rule That Surprises People You run a single cell with the Run button in the cell toolbar, or the whole notebook with Run all . You can also select a few lines inside a cell and run only the selection.
Here is the behaviour that trips up almost everyone arriving from SQL Server Management Studio. Microsoft states it plainly. “Each code cell is executed in a separate session, so the variables defined in one cell are not available in another cell.” Running a partial selection spins up a session too.
Follow that through and one consequence matters more than the rest. Fabric Data Warehouse supports session-scoped #temp tables, and a T-SQL cell is its own session, so a temp table created in one cell does not exist in the next one . Microsoft documents both halves separately rather than stating the conclusion, so treat it as a documented inference and test it in your own tenant before you build on it.
The workaround is straightforward. Keep anything that shares state inside a single cell, or persist the intermediate result to a real table instead of a temp table. An analyst who writes one long cell for a multi-step routine is working with the session model, which is exactly right.
Mixed-language notebooks behave sensibly here. A PySpark cell can sit above a T-SQL cell, and when you press Run all , Fabric offers to skip the non-T-SQL cells rather than failing on them.
Cross-Warehouse Queries With Three-Part Names A single query can span several warehouses. Microsoft’s mechanism is three-part naming, written as database.schema.table, where the database part is the name of the warehouse or SQL analytics endpoint.
SELECT s.OrderId,
s.OrderDate,
c.CustomerName,
i.QuantityOnHand
FROM SalesWarehouse.dbo.FactOrders AS s
JOIN CrmWarehouse.dbo.DimCustomer AS c ON c.CustomerKey = s.CustomerKey
JOIN InventoryLakehouse.dbo.StockLevels AS i ON i.SkuKey = s.SkuKey
WHERE s.OrderDate >= '2026-01-01';That query reads two warehouses and one lakehouse SQL analytics endpoint in a single statement. That capability is what makes the notebook worth opening, instead of running three exports and reconciling them in a spreadsheet .
Two boundaries apply. Cross-database queries only work inside the current active workspace, and Fabric does not support cross-region connections at all, so the source and target items have to sit in the same region.
There is also one exception that costs people an afternoon. CREATE VIEW does not accept three-part naming, so a view created from a cross-warehouse query always lands in the primary warehouse regardless of what the query reads.
Each cell opens and closes its own SQL session, which is why nothing carries forward between cells. Saving, Charting and Monitoring Query Results Three capabilities sit on the result grid, and all three are easy to miss because they only appear once you select query text.
Save as table writes the result of the selected query into a new table using a CREATE TABLE AS SELECT behind the scenes. Save as view creates a view from the same selection. Both live in the cell command bar, and both need a text selection first, which is why people who highlight nothing conclude the feature is missing.
Inspect is the charting entry point. It renders the data quality and distribution of each column in the returned result set, which is enough for a quick sanity read on a load . The results pane itself has a Table tab, and a dropdown appears when one run returns several result sets.
Run History Lives in the Recent Run View Notebook monitoring has a dedicated T-SQL tab inside the Recent Run view, reachable from the Run menu. It lists running, succeeded, cancelled and failed queries for the past 30 days, filterable by status or submit time and searchable by query text.
Each row carries a distributed statement ID, the query text up to 8,000 characters, submit time in UTC, duration, status, submitter and session ID. That session ID column is the practical way to confirm the per-cell session behaviour in your own tenant.
One detail saves a support ticket. Microsoft notes that historical queries “can take up to 15 minutes to appear in list” depending on concurrent workload. A run missing immediately after it finishes is almost certainly just late.
What the Fabric Warehouse T-SQL Surface Area Actually Supports Older guidance on this topic, including the earlier version of this article, described Fabric’s T-SQL as broadly limited and singled out identity columns and primary keys as things you could not have. That is no longer accurate, and in one case it never was.
Microsoft’s T-SQL surface area page is the authority here, and it now says outright that “Identity columns are supported in Fabric Data Warehouse.” Constraints exist too, with a condition attached.
Free Checklist
Microsoft Fabric Checklist
A practical readiness list covering workspace setup, capacity, warehouse design and governance, so the decisions around your notebooks are made before the first query runs.
Get the Checklist →
Capability Status in Fabric Data Warehouse What to know Identity columns Supported bigint only, no custom seed or increment, values are unique but not sequentialPrimary, foreign and unique keys Supported with a condition Only with NOT ENFORCED, and only via ALTER TABLE, never inline in CREATE TABLE MERGESupported, generally available No longer a gap, and the cleanest way to write an upsert TRUNCATE TABLESupported Works as it does in SQL Server Session-scoped #temp tables Supported Scoped to one session, so scoped to one notebook cell Common table expressions Supported Standard, sequential and nested CTEs all run, though nested CTEs are still preview ALTER TABLESubset only Add nullable columns, drop columns, add or drop NOT ENFORCED constraints. ALTER COLUMN is preview. Everything else is blocked Renaming a column Supported indirectly Use the sp_rename stored procedure Stored procedures, views, functions Supported Plus permissions and security roles Transactions Supported Snapshot isolation is enforced on every transaction, and table-level locking applies Default constraints Not supported Handle defaults in the insert instead Triggers Not supported Move the logic into the pipeline or the notebook Materialized views Not supported Persist the result to a table instead Recursive queries Not supported Flatten the hierarchy upstream Synonyms, SET ROWCOUNT, SET TRANSACTION ISOLATION LEVEL, FOR XML Not supported Microsoft warns these “might appear to succeed” while causing problems
Table 2. The current T-SQL surface area in Fabric Data Warehouse, verified against Microsoft Learn on 25 September 2026. The data type list deserves its own mention, because it is where a lift-and-shift from SQL Server breaks first. Fabric Data Warehouse tables do not support money, smallmoney, datetime, smalldatetime, datetimeoffset, nchar, nvarchar, text, ntext, image, tinyint, geography, geometry, json or xml.
Those types can still appear in variables, parameters and function outputs. The restriction is on persisted table and view columns, which is a distinction that decides how much of a migration script has to change.
Datasheet
Automating SQL Server to Microsoft Fabric Pipeline Migration
How FLIP converts SQL Server data pipelines into Fabric equivalents, and what the conversion does with the T-SQL and the data types that do not map cleanly to the Fabric surface area.
Read the Datasheet →
Working Examples That Run in Fabric Every example below is written to the surface area in Table 2, so each one runs as printed against a Fabric Data Warehouse. The earlier version of this article showed screenshots of a result grid instead of code, which is not something a reader can copy.
Create a Table With an Identity Column CREATE TABLE dbo.DimProduct
(
ProductKey bigint IDENTITY NOT NULL,
Sku varchar(32) NOT NULL,
ProductName varchar(200) NOT NULL,
Category varchar(64) NULL,
ListPrice decimal(18,2) NULL,
CreatedOn datetime2(6) NOT NULL
);Note what is absent. No PRIMARY KEY inline, because Fabric does not accept constraints inside CREATE TABLE. No IDENTITY(1,1), because a custom seed and increment are not supported . And datetime2(6) rather than datetime, with six digits of fractional-second precision, which is the documented maximum.
Add Constraints the Way Fabric Accepts Them ALTER TABLE dbo.DimProduct
ADD CONSTRAINT PK_DimProduct PRIMARY KEY NONCLUSTERED (ProductKey) NOT ENFORCED;
ALTER TABLE dbo.FactOrders
ADD CONSTRAINT FK_FactOrders_Product
FOREIGN KEY (ProductKey) REFERENCES dbo.DimProduct (ProductKey) NOT ENFORCED;NOT ENFORCED means the engine records the relationship for the query optimiser and for modelling tools, and does nothing to stop you inserting a row that violates it. Treat these as documentation of intent, and keep the actual validation in your load logic.
Upsert With MERGE MERGE INTO dbo.DimProduct AS target
USING stg.ProductFeed AS source
ON target.Sku = source.Sku
WHEN MATCHED AND target.ListPrice <> source.ListPrice THEN
UPDATE SET target.ListPrice = source.ListPrice,
target.ProductName = source.ProductName
WHEN NOT MATCHED BY TARGET THEN
INSERT (Sku, ProductName, Category, ListPrice, CreatedOn)
VALUES (source.Sku, source.ProductName, source.Category,
source.ListPrice, SYSDATETIME());MERGE is generally available in Fabric Data Warehouse, which closes what used to be the most-cited gap in the surface area. Older guides that tell you to write a delete-then-insert pattern are working around a limitation that is gone.
Validate a Load Inside One Cell WITH row_counts AS (
SELECT COUNT_BIG(*) AS staged FROM stg.ProductFeed
),
loaded AS (
SELECT COUNT_BIG(*) AS live FROM dbo.DimProduct
WHERE CreatedOn >= CAST(GETDATE() AS date)
),
dupes AS (
SELECT COUNT_BIG(*) AS duplicate_skus
FROM (SELECT Sku FROM dbo.DimProduct GROUP BY Sku HAVING COUNT_BIG(*) > 1) d
)
SELECT r.staged, l.live, d.duplicate_skus
FROM row_counts r CROSS JOIN loaded l CROSS JOIN dupes d;This is the shape a validation routine takes once you accept the session model. Everything that has to see everything else lives in one cell, joined through CTEs rather than staged through temp tables. The markdown cell above it explains to the next reader why each threshold is what it is.
Kanerika Service
Data Engineering on Microsoft Fabric
Warehouse design, pipeline build and migration validation delivered by a Microsoft Solutions Partner for Data and AI, with a Microsoft MVP leading the analytics practice.
Talk to Our Team →
Scheduling a T-SQL Notebook, and the Parameter Trap A notebook that only runs when somebody opens it is a development tool. Fabric gives you three ways to run one on a schedule, and then takes some of it back.
The first is the notebook’s own scheduler, where the notebook runs under the identity of whoever created or last updated the schedule. The second is a Data Factory pipeline with a Notebook activity , scheduled at the pipeline level, running under the identity of the pipeline’s last modified user. The third is the Job Scheduler REST API, which can trigger a run, cancel it, poll status and read an exit value for conditional orchestration.
Microsoft confirms all of this applies to T-SQL notebooks, listing “scheduling regular executions, and triggering execution within Data Integration pipelines” among the capabilities that carry over.
The Five Limitations That Break Naive Automation Now the part almost nobody writes about. The T-SQL notebook page carries a short, specific list of current limitations, and every one of them bites an orchestration design rather than a query.
Parameter cells are not supported. Microsoft is explicit that “the parameter passed from pipeline or scheduler won’t be able to be used in T-SQL notebook.” A parameterised daily run is not available.The monitor URL inside pipeline execution is not supported , so a failed run does not deep-link back the way other activities do.The snapshot feature is not supported , so you cannot capture the notebook state of a given run for later inspection.Service principals authentication is not supported. A scheduled T-SQL notebook cannot run as an application identity.Workspace identity is not supported , which removes the other common way to detach a scheduled job from a named person.Items four and five together have a governance consequence worth planning for. Every scheduled T-SQL notebook run is tied to a human account, so when that person changes teams or leaves, the job fails. Teams burned by this route the scheduled work through a stored procedure or a pipeline activity instead. The notebook then keeps the interactive and review work it is genuinely good at.
Item one has a cleaner workaround. If a run needs to vary by date or by entity, drive the variation from a control table the notebook reads , rather than from a parameter the scheduler cannot pass.
Every current limitation lands on orchestration rather than on the SQL you write. Source Control, Deployment and Governance for Notebooks A notebook that matters to the business belongs in source control, and Fabric supports that properly.
Git integration stores a T-SQL notebook as notebook-content.sql, where a PySpark notebook is stored as notebook-content.py. Cell output is not committed, so a diff shows the change in logic rather than the change in row counts. Deployment pipelines then move the notebook across development, test and production stages with auto-binding and deployment rules.
Notebook version history adds manual checkpoints alongside automatic ones every five minutes, with a diff view. That feature is in preview, and checkpoints expire after a year, so it complements Git rather than replacing it.
Who the Notebook Runs As Three trigger types, three identities, and the difference decides what a run can read .
An interactive run uses your identity. A pipeline run uses the identity of the pipeline’s last modified user. A scheduled run uses whoever created or last updated the schedule. Combine that with the service principal limitation above and you get the single most common cause of a job that worked in test and fails in production.
The governance answer is a naming and ownership convention applied before the notebook count gets large. Separate exploration notebooks from production ones by workspace or by folder, require a named owner on anything scheduled, and review the schedule owner list whenever somebody changes role. Fabric adoption programmes that skip this step end up with the notebook equivalent of an unmanaged report library.
On-Demand Webinar
Migrate to Microsoft Fabric 5X Faster with FLIP
A recorded session on how migration accelerators handle the mapping, validation and deployment work that notebooks and pipelines have to inherit afterwards.
Watch the Webinar →
When a T-SQL Notebook Beats a SQL Script or a Stored Procedure The notebook is not a replacement for the SQL query editor, and treating it as one produces worse outcomes than either tool on its own. Each of the three surfaces has a job it is best at.
The job T-SQL notebook SQL query editor Stored procedure Ad-hoc exploration of one table Works, slower to open Best fit Wrong tool A multi-step routine somebody else has to review Best fit , code and reasoning in one artifactLoses the reasoning Reviewable, but the intent lives in comments Data quality and reconciliation checks Best fit , results sit next to the thresholdsResults are not retained Works, but output handling is awkward A parameterised nightly job Not available, parameter cells are unsupported Not schedulable Best fit Running as a service principal Not supported Not applicable Best fit via a pipelineMigration validation across old and new platforms Best fit , cross-warehouse joins in one documentOne connection at a time Possible, harder to read Onboarding a new analyst to the warehouse Best fit , markdown carries the modelNo narrative No narrative
Table 3. Choosing between a T-SQL notebook, the SQL query editor and a stored procedure, by the job in front of you. The pattern that works in practice is a split by lifecycle rather than by preference. Exploration and validation happen in notebooks, where the reasoning is worth keeping. Anything that has to run unattended on a schedule becomes a stored procedure called from a pipeline , where parameters and service principals both work.
Case Study
74% Faster Retail Reporting with Microsoft Fabric
A US retail chain moved its legacy SQL reporting onto Microsoft Fabric and cut reporting cycles by 74%, with a 65% gain in reporting stability.
Read the Case Study →
Common Problems and How to Fix Them Five failures account for most of the support traffic on this feature, and each has a documented cause rather than a mysterious one.
What you see Why it happens What to do The warehouse will not attach, or the connection fails to authenticate Fabric does not support cross-region connections, and a notebook can only add items from the current workspace Confirm the warehouse and the notebook sit in the same workspace and the same region Invalid object name '#staging' in the cell after the one that created it#temp tables are session-scoped and each cell is its own sessionMove the dependent logic into the same cell, or write to a real table A view created from a cross-warehouse query appears in the wrong warehouse CREATE VIEW does not accept three-part naming, so the view lands in the primary warehouseSet the intended warehouse as primary before creating the view A scheduled run works for one person and fails for another The run uses the identity of whoever created or last updated the schedule, and service principals are unsupported Keep a named, current owner on every schedule, or move the job to a stored procedure in a pipeline A finished run is missing from the Recent Run list Query history can lag by up to 15 minutes under concurrent load Wait, then filter by submit time rather than assuming the run failed
Table 4. The five most common T-SQL notebook failures in Microsoft Fabric, with their documented causes. A sixth problem shows up less often but costs more. A team writes a migration script against Fabric as though it were SQL Server, and it fails on the data types rather than the syntax . Checking the type list in Table 2 before the first run saves the rewrite.
How Kanerika Runs T-SQL Workloads on Microsoft Fabric Most of the T-SQL work we see in Fabric arrives as part of a migration rather than as greenfield development. A team has years of SQL Server or Synapse logic , a reporting layer that depends on it, and a deadline. The notebook becomes the place where old and new get compared, because a cross-warehouse query can read both sides at once.
A US retail chain came to us with exactly that shape of problem. Report refresh cycles on their legacy SQL reporting layer had stretched, dashboards were losing stability as transaction volumes grew, and manual data preparation was producing numbers that did not match between reports.
We migrated the SQL-based reports to Power BI on Microsoft Fabric using our migration accelerator , and moved the input preparation and validation rules into Fabric pipelines so the manual step disappeared. The published outcome was 74% faster reporting cycles , a 65% increase in reporting stability , and 72% faster access to current metrics , with near-real-time sales and stock figures available to the business.
Published results from the retail SQL to Microsoft Fabric migration described above. The part of that work a T-SQL notebook is genuinely good at is the validation. You run the legacy aggregate and the Fabric aggregate side by side in one document, with the tolerance written in markdown above the query. That turns a migration sign-off from an argument into a review. FLIP, our workflow automation platform, handles the bulk conversion, and the notebook handles the proof.
Kanerika is a Microsoft Solutions Partner for Data and AI, and Amit Chandak, our Chief Analytics Officer, is a Microsoft MVP. If you are weighing up how much of your existing T-SQL estate moves cleanly into Fabric, that is a conversation worth having before the migration plan is written rather than after.
Wrapping Up T-SQL notebooks in Microsoft Fabric stopped being an experiment in June 2025, and the feature that shipped is more capable than most of the writing about it suggests. Identity columns work, MERGE works, cross-warehouse joins work, and the run history is there when you need to prove what happened.
The constraints that remain are specific rather than vague. Sessions are per cell, parameters do not reach a scheduled run, and service principals are not an option. Design around those three and the notebook becomes the best place in Fabric to do SQL work that somebody else will have to read.
Frequently Asked Questions
What is a T-SQL notebook in Microsoft Fabric? A T-SQL notebook is a Fabric notebook whose cells run Transact-SQL. You attach a Fabric Warehouse or a Lakehouse SQL analytics endpoint, and each cell queries it. The code, your written explanation and the query output all save together in one document. Microsoft released the feature for general use in June 2025.
How do I create a SQL notebook in Microsoft Fabric? There are two routes. From a Fabric workspace, select New item and choose Notebook. From an existing warehouse, open the top ribbon, select New SQL query and then New T-SQL query notebook. The second route arrives with the warehouse already attached, which saves a step when you know the target.
Is T-SQL the same as MSSQL? They describe different things. Transact-SQL is the query language, and Microsoft SQL Server is the database engine that runs it. You write T-SQL, and SQL Server executes it. The same language also runs on Azure SQL Database, Azure SQL Managed Instance and Microsoft Fabric, so the skills carry across products.
Why is it called T-SQL? T-SQL is short for Transact-SQL. The name comes from its origins as a transaction-oriented extension of SQL, developed at Sybase and later adopted and extended by Microsoft for SQL Server. The transactional part refers to the statements that group work into units. BEGIN TRANSACTION, COMMIT and ROLLBACK mean a batch either finishes or undoes itself cleanly.
What types of SQL commands can I run in a Fabric T-SQL notebook? All four families run against a Fabric Warehouse. Definition commands such as CREATE, ALTER and DROP shape tables. Manipulation commands such as SELECT, INSERT, UPDATE, DELETE and MERGE move rows. Control commands such as GRANT and REVOKE manage permissions. Transaction commands such as COMMIT and ROLLBACK group related work together.
What is DDL, DML, DCL and TCL? They are the four categories of SQL statements. DDL defines database structure, so CREATE, ALTER, DROP and TRUNCATE belong there. DML reads and changes rows through SELECT, INSERT, UPDATE and DELETE. DCL handles permissions with GRANT and REVOKE. TCL controls transaction boundaries with COMMIT, ROLLBACK and SAVEPOINT, so a group of related changes lands or reverses as one.
What are the key components of T-SQL? Transact-SQL combines several building blocks. Query statements read data, and data modification statements change it. Variables and control-of-flow keywords such as IF, WHILE and BEGIN add procedural logic. Stored procedures and functions package reusable code. Error handling uses TRY and CATCH, and transaction statements group work so it commits or rolls back together.
What is the difference between T-SQL and PL/SQL? Both extend SQL with procedural features, for different engines. Transact-SQL is Microsoft’s dialect, running on SQL Server, Azure SQL and Microsoft Fabric. PL/SQL is Oracle’s dialect, running on Oracle Database. The syntax differs in variable declaration, error handling, cursors and built-in functions, so code rarely moves between them without a rewrite.
What is the difference between KQL and T-SQL? Kusto Query Language reads large volumes of log and telemetry data in near real time, and it powers Real-Time Intelligence in Microsoft Fabric. Transact-SQL queries relational tables in a warehouse or a SQL analytics endpoint. KQL uses a piped, left-to-right syntax, while T-SQL uses the familiar SELECT and FROM structure.
Are MySQL and T-SQL the same? No. MySQL is an open-source database engine, and its procedural dialect is its own. Transact-SQL is Microsoft’s dialect, used by SQL Server, Azure SQL and Microsoft Fabric. Both accept core ANSI SQL, so simple SELECT statements often run on either. Anything using procedural syntax, functions or data types usually needs changes.
Is T-SQL easy to learn? For anyone who already knows basic SQL, the first steps are quick, because SELECT, JOIN and WHERE behave as expected. The procedural parts take longer, particularly stored procedures, transactions, window functions and execution plans. Working inside a Fabric notebook helps, because you can run one cell at a time and read the result immediately.
What are SQL notebooks? A SQL notebook is a document made of cells, where SQL, written explanations and query output sit together and save as one file. It suits exploration, data quality checks and analysis that somebody else will review later. Visual Studio Code, Microsoft Fabric and several cloud analytics platforms all ship a version of the format.
What are notebooks in Microsoft Fabric? A Fabric notebook is an item made of cells that hold code, markdown or query results. It supports several languages, including PySpark, Python, Spark SQL and T-SQL. Notebooks handle exploration, transformation and data validation work, and several people can edit the same notebook at once with live cursors and cell comments.
How do I import a notebook into Microsoft Fabric? From a Fabric workspace, choose Import notebook and select the files from your computer. Fabric reads standard Jupyter .ipynb files and source files with .py, .scala and .sql extensions. You can import more than one at a time. After import, open the notebook and attach the warehouse or lakehouse it should run against.
What SQL language does Microsoft Fabric Warehouse support? Fabric Data Warehouse runs Transact-SQL, with a smaller surface area than SQL Server. Tables, views, stored procedures, functions, security roles, identity columns, MERGE, TRUNCATE and session temp tables all work. Triggers, materialized views, recursive queries and synonyms do not. Several SQL Server data types are also unavailable for table columns.
Can I run T-SQL inside a Fabric Python notebook? Yes. Microsoft documents a magic command that runs Transact-SQL from a cell in a Python notebook. It takes a type argument, so a cell can target a Warehouse, a Fabric SQL database or a Lakehouse endpoint. It can also bind results into a Python variable. The feature is in preview.
Can I schedule a T-SQL notebook in Microsoft Fabric? Yes, through the notebook scheduler, a Data Factory pipeline Notebook activity, or the Job Scheduler REST API. One limit matters for automation. Parameter cells are not supported in T-SQL notebooks, so a scheduler cannot pass a value in. Service principal authentication and workspace identity are also unsupported for these runs.
Can a T-SQL notebook query more than one warehouse? Yes. Three-part naming, written as database, schema and table, lets a single query join tables across warehouses and Lakehouse SQL analytics endpoints. Both items must sit in the same workspace, and Fabric does not support connections across regions. Creating a view from a cross-warehouse query always lands it in the primary warehouse.
Does a temp table survive between cells in a T-SQL notebook? No. Microsoft states that each code cell runs in a separate session, and temporary tables in Fabric Data Warehouse are scoped to a session. A temp table built in one cell will not be visible in the next one. Keep dependent steps inside a single cell, or write the intermediate result to a real table.
What is T-SQL used for? Transact-SQL is Microsoft’s extension of SQL, used to query and change data in SQL Server, Azure SQL and Fabric Data Warehouse. It adds procedural features such as variables, error handling, control-of-flow statements and built-in functions. Analysts use it for reporting queries, and engineers use it for loads, transformations and stored procedures.
What is the difference between T-SQL and standard SQL? Standard SQL is the ANSI specification for querying relational data. Transact-SQL implements that standard and adds Microsoft-specific features on top, including variables, TRY and CATCH error handling, control-of-flow keywords and a large function library. Queries written in plain ANSI SQL generally run under T-SQL, while T-SQL extensions do not port to other engines.
Is SQL the same as T-SQL? No. SQL is the general query language that many database engines implement. Transact-SQL is Microsoft’s own dialect of it, used across SQL Server, Azure SQL and Microsoft Fabric. Every valid ANSI SQL statement is usually valid T-SQL, but T-SQL adds procedural extensions that other engines such as Oracle or MySQL do not understand.
