Design decisions
The decisions behind OneLake Studio, and why we made them. For the parts of the app and how they connect, see Architecture.
One SQL name for every object
Every table, file and semantic model in your tenant has one SQL name. The name is where Fabric keeps the object, with its type first.
| Object | Its name | Example |
|---|---|---|
| A table | <kind>.<workspace>.<item>.<schema>.<table> | lakehouse.demo.data.aemo.duid |
| A semantic model | semanticmodel.<workspace>.<model> | semanticmodel.demo.DL |
| A file | 'lakehouse.<workspace>.<item>/Files/<path>' | 'lakehouse.demo.data/Files/x.parquet' |
Why: Fabric makes workspace names unique in a tenant, item names unique for their type in a workspace, and table names unique in a schema. So each name points to exactly one object, and a query that joins tables from different workspaces can't read the wrong one. If one name could mean two objects, a query could return wrong data without an error.
The names are real SQL. The kind is a DuckDB catalog, the workspace, item and schema are schemas inside it, and each table is a view.
SQL only
Everything is queried with SQL, semantic models included. A Power BI semantic model is read as one table, and AGG("measure") computes a measure:
SELECT duid.Region, AGG("Mwh") AS mwh
FROM semanticmodel.demo.DL
GROUP BY ALL;
Why: one language for tables and models means one query can join both, and anyone who knows SQL can use a model. dax-sql compiles the model's measures to SQL, and DuckDB runs it. There are no DAX queries. Matching Power BI's DAX results in every case is not a goal, so a result can differ from Power BI in edge cases.
Opening a model reads its definition from the Fabric REST API once and keeps it on your machine. Only Direct Lake models are supported, over a lakehouse or a SQL endpoint, and their tables are read from OneLake. Reading a model's definition needs the Contributor role or higher on the workspace, or write permission on the model.
Read only
OneLake Studio never changes your data. Every statement is checked before it runs: only one statement at a time, and only one that reads. The only feature that writes is Export to Fabric, and it asks you first.
Why: you can point it at production data without risk, and so can an agent.
Runs on your machine
DuckDB runs on your machine and reads OneLake directly, with your own sign-in. There is no service in between, and no app to register in your tenant.
Why: nothing to deploy or pay for, your data goes only between OneLake and your machine, and you see only what your account can already see.
Works offline
Everything you have read is kept on your machine and keeps working without internet. Nothing needs to be turned on. When you are offline, the status bar says so, and no request is sent, so nothing waits for a timeout.
| Works offline, once read | Needs OneLake |
|---|---|
The tree, SHOW ALL TABLES, information_schema, Go To | A column or a file never read |
| A table's Stats and History, and first rows already read | A wildcard over files |
Semantic models: opening them, the Model page, SHOW SEMANTIC … | A table whose metadata was never read |
| Table rows, model queries and the Pivot, for data already read | Export to Fabric |
Files/ objects read before |
The cache is per Microsoft account, so one account never sees another's data. It is kept when you sign out, and only Clear Cached OneLake Data deletes it.
Why: you can work on a plane or a slow connection, and a query on data you have read doesn't wait for the network.
Agents
Claude Code and GitHub Copilot use OneLake Studio through its command line, with the same access you have. Install Agent Skill, in the app or in VS Code, sets it up. The command line asks the running app or VS Code, and if neither is open, it runs on its own.
The answer goes to stdout and notes go to stderr. --json gives a structured answer, and exit codes say what happened, such as 3 for not signed in and 4 for data that isn't cached.
Not in scope
Matching Power BI's DAX behavior 100% is not a goal. Measures are compiled to SQL and run in DuckDB, so results can differ from Power BI in edge cases. Also not in scope:
- DAX queries (
EVALUATE). - Writing to OneLake, DDL, or editing data in the grid.
CREATEandDROP SEMANTIC VIEW: a model exists because Fabric has it.- A TDS connection to the SQL endpoint.
- Diagrams for lakehouse tables, since they declare no keys.
- vscode.dev: the engine is a native library, so the extension needs desktop VS Code.