Can I write to a Fabric lakehouse with T-SQL?

Not to its tables. The SQL analytics endpoint is read-only over the lakehouse's Delta tables, although you can create your own views, functions and stored procedures there. To write, use Spark notebooks, pipelines or dataflows. If your team needs to insert, update and merge with T-SQL, that is the signal to add a Fabric warehouse.

Is a Fabric warehouse faster than a lakehouse?

Not by default. Both are queried by the same SQL engine and store Delta tables in OneLake. Speed depends far more on table design: file sizes, regular maintenance, sensible string lengths and good data types. The warehouse handles compaction automatically, while lakehouse tables written by Spark benefit from scheduled maintenance, so a neglected lakehouse can feel slower.

When do I really need multi-table transactions?

When several tables must change together or not at all. Typical cases are loading a fact table with its audit record, applying journal postings that must balance, or swapping a set of related tables during a reload. If each table can be loaded and retried independently, a lakehouse with per-table Delta transactions is usually enough.

Can I start with a lakehouse and add a warehouse later?

Yes, and many teams do. Because both items use OneLake and the same SQL engine, a new warehouse can query existing lakehouse tables with three-part names. That means you can move just the gold layer into T-SQL when your reporting team needs transactions or SQL security, without rebuilding the bronze and silver layers you already run in Spark.

Can Power BI Direct Lake use both lakehouse and warehouse tables?

Yes. Both store their tables in Delta format in OneLake, so Direct Lake semantic models can be built on either. The practical difference is timing: with a lakehouse, make sure your load and endpoint refresh have finished before the model refreshes, so reports do not show yesterday's data.

Fabric Lakehouse vs Warehouse: How to Choose, and When to Use Both

Choose a Fabric lakehouse when your team builds with Spark notebooks, works with files as well as tables, or runs a medallion pipeline. Choose a Fabric warehouse when your team writes T-SQL, needs multi-table transactions, or wants SQL-native security such as dynamic data masking. Both store Delta tables in OneLake and share the same SQL engine, so many teams sensibly use one of each.

At a glance

Question	Lakehouse	Warehouse
Main way to write data	Spark, pipelines, dataflows	T-SQL, pipelines, dataflows
T-SQL access	Read-only SQL analytics endpoint	Full read and write
Multi-table transactions	No	Yes
Raw files and unstructured data	Yes	No, structured tables
Fine-grained security	OneLake security roles	T-SQL permissions, RLS, CLS, masking

What is the same, and what is not

Microsoft's own decision guide makes a point many teams miss: the two items are closer than they look. Both store data as Delta tables in OneLake, both are queried by the same SQL engine, both feed Power BI Direct Lake models, and both run on the same Fabric capacity. A warehouse can query a lakehouse table with a three-part name, and a notebook can read a warehouse table, without copying data.

The real difference is who writes the data, and how.

A lakehouse is written by Apache Spark (Python, Scala, Spark SQL or R), pipelines, dataflows and OneLake shortcuts. It has a Tables area for Delta tables and a Files area for raw files of any kind. Every lakehouse gets a SQL analytics endpoint automatically. It is read-only over the lakehouse tables: you can add your own views, functions and stored procedures, but you cannot INSERT, UPDATE or CREATE TABLE there.
A warehouse is written with T-SQL: COPY INTO, INSERT, CREATE TABLE AS SELECT, UPDATE, DELETE and MERGE, which is now generally available. It also loads from pipelines and dataflows, and supports multi-table ACID transactions, identity columns, temp tables and stored procedures.

So the better question is not "which is better?" but "which engine should own each table?".

Decision 1: What does your team already write?

Start with skills, because that is where Microsoft's decision tree starts.

If your engineers live in notebooks and PySpark, a lakehouse is the natural home. Analysts who only read data can still use T-SQL through the SQL analytics endpoint, so they do not force you into a warehouse.
If your team has years of SQL Server or Synapse T-SQL, stored procedures and SQL Server Management Studio habits, a warehouse lets that code and those habits carry over. The Fabric Migration Assistant for Data Warehouse can help move existing SQL Server and Synapse code.
Mixed teams are normal. The usual split is Spark for ingestion and heavy transformation, and T-SQL for the dimensional model and business rules.

A common mistake is treating "we need SQL" as the deciding factor. If the SQL users only read, the endpoint already gives them T-SQL.

Decision 2: How does your data change?

Write patterns decide more than people expect.

Append-heavy, file-shaped or semi-structured data belongs in a lakehouse: CSV drops, JSON from APIs, logs, images. Spark handles large file volumes and changing schemas well, and Delta gives you ACID writes per table, schema enforcement and time travel.

Changes that must land together belong in a warehouse. If loading a sales fact, updating a customer dimension and writing an audit row must all succeed or all roll back, only the warehouse gives you one transaction across several tables. Warehouse transactions use snapshot isolation and can span other warehouses in the same workspace, including reads from a lakehouse SQL analytics endpoint.

BEGIN TRANSACTION;

INSERT INTO dbo.FactSales (DateKey, CustomerKey, NetAmountGBP)
SELECT s.DateKey, c.CustomerKey, s.NetAmount
FROM SilverLakehouse.dbo.sales AS s
JOIN dbo.DimCustomer AS c
    ON c.CustomerId = s.CustomerId
WHERE s.LoadDate = '2026-10-24';

UPDATE dbo.LoadAudit
SET LastLoadedDate = '2026-10-24'
WHERE TableName = 'FactSales';

COMMIT TRANSACTION;

Here the warehouse reads cleaned rows from a lakehouse called SilverLakehouse, then commits the fact load and the audit update as one unit. If either statement fails, neither change is kept.

Two concurrency facts to design around:

The warehouse locks at table level. Two transactions that UPDATE, DELETE or MERGE the same table at the same time can conflict even when they touch different rows, and one fails with a snapshot isolation error. Run writers to the same table one after another, and add retry logic to pipelines and procedures.
Lakehouse Delta tables use optimistic concurrency with serializable isolation, so parallel MERGE or UPDATE jobs on one table can also fail. The fix is the same: avoid parallel writers to a single table.

Decision 3: How will you secure it?

This is where the two differ most, and where any team handling personal data should spend real time.

Warehouse security is T-SQL. You use GRANT and DENY on objects, row-level security through security policies, column-level security and dynamic data masking. If your database administrators already work this way, nothing new is needed.

Lakehouse security has two layers. Workspace roles (Admin, Member, Contributor, Viewer) control what people can do. OneLake security roles control which tables, folders, rows and columns a reader sees, and are enforced across Spark, the SQL analytics endpoint and Power BI. Two details catch people out:

OneLake roles mainly restrict readers. Admins, Members and Contributors already have read and write access to all data in the workspace, so OneLake roles largely do not limit them. Give analysts the Viewer role plus OneLake roles, not Contributor.
The SQL analytics endpoint has an access mode. New endpoints start in delegated identity mode: the endpoint reads OneLake as the item owner, and security is defined in SQL, including dynamic data masking. In user identity mode, the signed-in user's identity is passed to OneLake, OneLake roles govern table access, and SQL GRANT statements on tables are ignored. OneLake security does not support dynamic data masking, so if you need masking on lakehouse data, use delegated mode or serve that data from a warehouse.

Switching an endpoint's access mode briefly makes every SQL analytics endpoint in the workspace unavailable and cancels running queries, so schedule it out of hours.

Decision 4: Can your reports live with endpoint sync?

A lakehouse table written by Spark becomes visible to T-SQL through a background metadata sync. Microsoft says the lag is under a minute in normal conditions, but it can stretch to several minutes, and the background process stops after 15 minutes without query activity. Many small files, very large ETL batches and lots of lakehouses in one workspace all slow it down.

Practical fixes:

Refresh before reporting. Add the Refresh SQL analytics endpoint activity at the end of your pipeline, before any semantic model refresh. You can also refresh from the portal or the REST API.
Maintain busy tables. Schedule table maintenance on Delta tables that are updated often, so file counts stay under control.
Spread out lakehouses. Automatic metadata discovery runs as a single instance per workspace, so very busy workspaces benefit from being split.
Try the new metadata sync. Announced in preview in May 2026, it aims to make data queryable within seconds. It applies only to endpoints created after you turn it on in workspace settings, and it cannot currently be enabled with workspace private link.

A warehouse has no equivalent step: a committed T-SQL write is visible to the next query.

The pattern most teams end up with

For most organisations the answer is both, in layers.

Bronze and silver in a lakehouse. Land raw files, then clean and conform them with Spark. Our guide to medallion architecture in Fabric walks through the layers.
Gold in a warehouse when your modellers and report writers think in T-SQL and you want transactions and SQL security on the final tables. Load it with cross-database T-SQL, as above, or from a notebook with the Spark connector for Fabric Data Warehouse, which writes to warehouse tables but not to a SQL analytics endpoint.
Gold in a lakehouse is equally valid when the team is Spark-first and read-only SQL is enough for consumers.

Keep the items in the same region. Microsoft lists cross-region connections for warehouses and SQL analytics endpoints as unsupported, so a lakehouse on a UK South capacity and a warehouse on a capacity in another region may fail to connect.

Mistakes worth avoiding

Undefined string lengths. Spark string columns with no defined length appear to the SQL engine as varchar(8000), which hurts query performance. For tables you serve to SQL users, define varchar(n) in a Spark SQL CREATE TABLE statement.
Contributor for everyone. It sidesteps most of OneLake security. Use Viewer plus OneLake roles for readers.
Reports refreshing before sync. Build the endpoint refresh into the pipeline.
One giant workspace. It slows metadata sync and blurs security boundaries.
Choosing by habit. Decide per table: which engine writes it, who reads it and what security it needs.

How CertTulen Academy can help

CertTulen Academy runs live, MCT-led Microsoft Fabric training online, with hands-on labs. If your gold layer is heading for T-SQL, the one-day DP-602 Implement a Data Warehouse with Microsoft Fabric course is the focused option. If you build the lakehouse side with Spark and pipelines, DP-700 Microsoft Fabric Data Engineer goes deeper and prepares you for the exam. Unsure which exam comes first? Read DP-600 vs DP-700, or contact us for a batch that suits your time zone.