Forum Discussion
Developing Fabric Notebooks in VS Code - What's the current best setup?
Hello gusy!
I'm working on a Fabric project (migrating local analytics into a Medallion architecture — Bronze → Silver → Gold) and I'd love to improve my development experience by moving away from the browser-based notebook editor.
Specifically, I want to understand:
1. **VS Code + Fabric Notebooks** — Is there a reliable way to develop Fabric notebooks locally in VS Code today? I'm thinking about things like GitHub Copilot, IntelliSense, better code navigation, and all the productivity wins that come with a proper IDE. I tried the Fabric VS Code extension a while back and had a rough experience, has this improved significantly recently?
2. **Connecting to the Lakehouse from VS Code** — When running notebooks locally (or in a remote session), can I actually hit my Fabric Lakehouse for reads/writes? Or is local development mainly useful for logic/unit testing with mocked data, while execution still has to happen in the Fabric portal? If yes, how I can streamline the process on easily get some data from the lakehouse and test the transformations etc?
3. **Recommended workflow** — What's the setup you'd actually recommend for someone who wants a productive, AI-assisted coding experience but still needs to deliver against a real Fabric environment?
For context: I'm not a full-time data engineer, I work as data consultant, and I'm progressively building my DE skills, so I'm looking for a setup that's practical and doesn't take weeks to configure. Happy to hear what's working for others!
Thanks in advance 🙏
Hello robertozsr
If you are referring to Fabric Data Engineering VS Code extension, it is indeed the appropriate way to develop Fabric notebooks locally using Visual Studio Code. The extension enables you to click on Open in VS Code button on Fabric UI to open it locally in your VS Code. It comes with Git integration, allows you to run local Fabric runtimes, and can also execute your code on remote Spark compute on Fabric.
Within VS Code you get the usual perks, GitHub integration, CoPilot etc. If you have used it a while back, I suggest you should give it a try again.
In regards to connecting to a Lakehouse, when you code runs on remote cluster, it can read/write from a Lakehouse in the same way it would from the Fabric portal. If you plan to connect from local environment, you'd have to use the ADLS APIs and authenticate using Microsoft Entra, just like you'd do for any storage account on Azure. I would suggest you run your code on remote Fabric Spark, rather than running it locally, simply because your code is destined for Fabric anyway if you're planning to schedule it as part of your pipeline.
The recommended approach in my view would be to use Fabric Data Engineering VS Code Extension to develop your notebooks locally, but run it on remote Spark via Microsoft Fabric Runtime. You should write reusable code in Python modules, just like you do in any other projects, and use Notebooks for transformation and orchestration.
4 Replies
Hello robertozsr
If you are referring to Fabric Data Engineering VS Code extension, it is indeed the appropriate way to develop Fabric notebooks locally using Visual Studio Code. The extension enables you to click on Open in VS Code button on Fabric UI to open it locally in your VS Code. It comes with Git integration, allows you to run local Fabric runtimes, and can also execute your code on remote Spark compute on Fabric.
Within VS Code you get the usual perks, GitHub integration, CoPilot etc. If you have used it a while back, I suggest you should give it a try again.
In regards to connecting to a Lakehouse, when you code runs on remote cluster, it can read/write from a Lakehouse in the same way it would from the Fabric portal. If you plan to connect from local environment, you'd have to use the ADLS APIs and authenticate using Microsoft Entra, just like you'd do for any storage account on Azure. I would suggest you run your code on remote Fabric Spark, rather than running it locally, simply because your code is destined for Fabric anyway if you're planning to schedule it as part of your pipeline.
The recommended approach in my view would be to use Fabric Data Engineering VS Code Extension to develop your notebooks locally, but run it on remote Spark via Microsoft Fabric Runtime. You should write reusable code in Python modules, just like you do in any other projects, and use Notebooks for transformation and orchestration.
Thanks for the answer!
Hi robertozsr ,
Thanks for reaching out to Microsoft Fabric Community.Just wanted to check if the response provided by deborshi_nag was helpful. If further assistance is needed, please reach out.
Thank you.Hi robertozsr,
Great questions! I've been using the Fabric VS Code extension on a Medallion architecture project, so here's what's actually working in practice.
1. Has the VS Code extension improved?
Yes, significantly. The main improvements you'll notice compared to a while back:
- Remote Spark execution directly from VS Code your notebook runs on Fabric's cluster, not locally
- Git-native workflow notebooks sync as .ipynb files with your workspace automatically
- GitHub Copilot integrates naturally alongside it
- IntelliSense is usable, though not as rich as a pure Python project
The rough experience you remember was likely before the remote runtime was stable. Worth trying again.
2. Connecting to the Lakehouse
Two modes in practice:
- Remote execution (recommended): Run on Fabric Spark from VS Code → reads/writes to the Lakehouse work exactly as in the portal. Zero extra setup. This is what you want for actual data work.
- Local execution: Possible via ADLS Gen2 API + Entra auth, but overkill unless you're doing pure Python/pandas logic that doesn't need Spark.
For a Medallion project, remote execution is the answer.
3. Recommended workflow for your situation
Here's the setup I'd recommend realistically an afternoon to get running, not weeks:
- Install the VS Code extension → connect your workspace → open any notebook via "Open in VS Code" from the Fabric portal
- Develop with Copilot + IntelliSense, commit to a feature branch via Git
- Run on remote Spark whenever you need real data validation against your Lakehouse
- Use the Fabric portal only for monitoring runs or stakeholder sharing
This gives you the full IDE experience without losing access to your real data.
Hope this helps!
