Please reconsider retiring Azure Data Studio – VS Code is too cluttered for SQL workflows

[Hilden202]

I appreciate all the work put into Azure Data Studio, and I just wanted to say that I personally prefer it over using SQL extensions in Visual Studio Code.

VS Code becomes too cluttered when I add SQL tools on top of everything else, and I really miss the simple and focused environment that ADS provides.

One of the key features I rely on is the Explorer pane in ADS, where I can keep my SQL queries organized in well-structured folders with descriptive names. This makes it much easier for me to navigate and manage multiple queries, especially during development and testing.

As someone working on macOS, I don’t have access to SSMS, so Azure Data Studio is the only full-featured SQL tool that fits well into my workflow. Being forced to move everything into VS Code makes things harder, not better.

Please consider continuing support for ADS, or at least bringing some of its structure and clarity into the SQL extensions for VS Code.

[kburtram]

@Hilden202 thanks for the feedback! Could you please help us understand if there's any specific gaps in our roadmap for the vscode-mssql extension that could make it work better for you? We're planning to introduce Server Group folders to the vscode-mssql Connections tree in June, for example.

There's only so much we can do about "general clutter" in VS Code, since a lot of that is coming from other extensions, but at least within the SQL panes and documents we're hoping to keep the UX focused and streamlined. Making the VS Code extension feel like a natural continuation, and hopefully an improvement, from ADS is a core goal of what we're trying to do there.

[Hilden202]

Hi and thanks for the follow-up!

As a student who works regularly on both Mac and PC, I’ve come to rely on Azure Data Studio for my SQL workflows – and I genuinely prefer it over both SSMS and the current experience with SQL in VS Code.

What I really appreciate about ADS is how it gives SQL its own focused space. When writing or testing queries, switching to a dedicated environment helps me mentally shift into “database mode,” instead of mixing SQL with all the other tabs I have open in VS Code (HTML, JS, etc.). It just feels more streamlined and focused.

Another highlight is the Explorer pane in ADS, where I’ve organized saved queries into folders with descriptive names. This makes it much easier to manage, reuse, and navigate scripts – something that’s hard to replicate in VS Code without additional setup.

I understand you’re working on enhancing the vscode-mssql extension, and it’s great to hear about the upcoming improvements. Personally, I’d still love to see:
• A simple folder-based query explorer
• A more “detached” SQL workspace feel
• Less visual noise and clearer separation when working with data

Thanks again for listening to feedback – looking forward to seeing where things go from here.

[LarnuUK]

@Hilden202 thanks for the feedback! Could you please help us understand if there's any specific gaps in our roadmap for the vscode-mssql extension that could make it work better for you? We're planning to introduce Server Group folders to the vscode-mssql Connections tree in June, for example.

There's only so much we can do about "general clutter" in VS Code, since a lot of that is coming from other extensions, but at least within the SQL panes and documents we're hoping to keep the UX focused and streamlined. Making the VS Code extension feel like a natural continuation, and hopefully an improvement, from ADS is a core goal of what we're trying to do there.

Hi @kburtram ,

Earlier today, a bunch of Issues on the VSCode MSSQL repo were closed as "not planned". Many of these were asking for basic functionality, such as:

• Support for Ctrl+N to open a new query
• Support for F5 to execute a query/execute the highlighted query (there is at partial documented work around)
• Support for SQL Server Agent
• Support for Central Management Servers

I've not tried them, but I've heard users trying to migrate from Python Notebooks to Polyglot notebooks are having a poor time (one reason I believe is that Polyglot needs a .Net install needing admin privileges and many don't have those at work environments).

The documentation even states that for database administration to switch to SSMS; SSMS is Windows ONLY, so that isn't a solution for ADS' Windows and Linux users. If Windows were free maybe I'd consider spinning up a VM, but with the cost of purchases Windows 11, and the TPM requirements it has (which is needed for the VM too) that can be difficult unto itself. I remember many many years ago the reason I switched to Linux was because I couldn't afford the Windows Licence (it wasn't a good time); sure I'm not in that position now, but I still use Linux now as a daily driver as I ended up preferring the experience. Why make users fork out money to do a basic task because the migration path refuses to support it? Certainly I have no plans to pay for Windows 11 just to use SSMS.

The thing is VSCode and ADS fulfil very different roles, and pushing users from ADS into VSCode is like pushing SSMS users into Visual Studio; both are based on the same shell (ADS on VSCode and SSMS on VS), but they are not the same product. Both ADS and SSMS are designed for Database users in mind; VS and VSCode are for programming in mind. Database users and Programmers work very differently.

That so many issues are already being closed as not planned fills me with significant concern that early next year, I'm going to end up using a slowly aging version of ADS, that will one day sadly break, and I'll have no migration path; VSCode-MSSQL in its current, and planned state, is not a valid path.

[Hilden202]

I just wanted to echo the concerns raised above – especially regarding how tools like ADS provide a smoother, purpose-built experience for database users, something that’s hard to replicate in VS Code as it stands today. I’m also concerned about the increasing number of “not planned” issues, which makes it hard to see a viable path forward for macOS and Linux users.

[Lindsay-Mathieson]

Agree, ADS is a superior experience to VS Code, do not want to be using a 2nd class citizen extension via it.

[LarnuUK]

Not to mention, and I probably should have done, my points come from a SQL Server perspective, only. ADS is not only supported on many operating systems, it also supports multiple RDBMS natively. VS Code needs an extension for each, and each likely has significantly different implementations, rather than something more generic.

Admittedly, however, I cannot make any comments from a different RDBMS perspective.

[LarnuUK]

To keep things "piling on", I want to quote a comment from an issue that I created about the VSCode MSSQL Extention lacking the functionality of ADS, and it not being a replacement:

However, it’s important to clarify that the MSSQL extension for Visual Studio Code is not intended to be a one-to-one replacement for Azure Data Studio or SSMS. Our vision is to provide a modern, lightweight, developer-first experience that integrates naturally into the VS Code ecosystem.

This is an excellent example of why this retirement is a problem; Microsoft don't plan to actually provide users with the functionality that ADS has in VSCode. As such, people are being misled; the retirement just means there's going to be hole where the product existed, as there' actually no migration path, by Microsoft, for ADS' users, nor is there planned to be.

[LarnuUK]

I'm guessing that the silence means that there's no change in stance here.