SQL Server development in VS Code after Azure Data Studio

Microsoft retired Azure Data Studio on 28 February 2026. Its recommended replacement is Visual Studio Code with the MSSQL extension, which Microsoft now develops as its main cross-platform SQL tool. SQL Server Management Studio, now at version 22, remains the Windows tool for administration.

If you write T-SQL every day, especially stored procedures, VS Code has become a good place to do it. This article sets it up from scratch: the extensions, a local SQL Server, a workflow for procedures, and the tools for debugging and performance.

What you need

1. VS Code, on Windows, macOS or Linux.
2. The MSSQL extension (ms-mssql.mssql) from Microsoft: connections, Object Explorer, IntelliSense, query results, execution plans.
3. Optionally, SQL Database Projects (ms-mssql.sql-database-projects-vscode), to keep a database’s schema as .sql files and build it into a DACPAC.
4. Optionally, SpDev, to run and debug stored procedures step by step, and with SpDev Pro, profile them.

A local SQL Server in Docker

A development database on your own machine is worth having: you can break it, reset it and profile it without affecting anyone. SQL Server 2022 runs in Docker on Windows, macOS (Intel and Apple silicon, through emulation) and Linux:

docker run -d --name sql2022 \
  -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Use-A-Strong-Password-1" \
  -p 1433:1433 \
  mcr.microsoft.com/mssql/server:2022-latest

The image runs the free Developer edition by default, which has every Enterprise feature for non-production use. Connect with:

Server=localhost,1433;Database=master;User Id=sa;Password=Use-A-Strong-Password-1;TrustServerCertificate=true

TrustServerCertificate=true is needed because the container uses a self-signed certificate; don’t use it for real servers. To follow the examples on this blog, run the SpDevDemo script once.

What the MSSQL extension gives you

As of late 2026:

• Connections and Object Explorer: browse servers, databases, tables, views, procedures and functions; search for objects by name. Backup and restore from Object Explorer is in preview.
• IntelliSense for T-SQL: completion of tables, columns and procedures, and errors underlined as you type.
• Running queries: the results grid, with export to CSV, JSON and Excel, and the messages pane.
• Execution plans: an Estimated Plan button next to Run Query, and Enable Actual Plan to capture the plan of the queries you run, shown in a graphical plan viewer.
• Schema Designer to view and change tables visually.
• Query Profiler (preview) to watch the activity on a server live, Profiler-style.
• GitHub Copilot integration, if you use it.

The extension changes every month; Microsoft publishes a summary of each release on the Azure SQL dev blog.

What’s still better in SSMS

SSMS 22 is still the more complete administration tool: SQL Server Agent jobs, security and permissions dialogs, Always On, replication, the built-in performance reports and the activity monitor. Many developers keep both: VS Code for writing and testing code, SSMS for administering servers.

A workflow for stored procedures

The most useful change you can make when moving to VS Code is to treat procedures as source code, not as objects that live only in the database.

1. One file per procedure, in Git. For example sql/procedures/dbo.GetCustomerOrders.sql, written as CREATE OR ALTER PROCEDURE, so running the file deploys it. A SQL Database Project gives you the same structure with a build step that checks references.

2. Edit with IntelliSense. Connect the editor to your development database (the MSSQL extension asks, or uses the connection you pick in the status bar), and you get completion and error checking against the real schema.

3. Run and debug the file, not the deployed copy. With SpDev, each procedure file gets Run and Debug buttons above CREATE PROCEDURE. SpDev asks for the parameters, then runs your local file as a temporary procedure. Debugging stops on the first line: step with F10 and F11, watch every variable and temp table, step into the procedures it calls from their own local files, and step back when you’ve gone too far. You test the change before deploying anything.

4. Look at performance before review. With SpDev Pro, Profile runs the procedure once and shows the cost of every line, with the problems found in the actual plans (missing indexes, implicit conversions, parameter sniffing, spills) on the lines that cause them. Profile again after a change to compare.

5. Deploy by running the file against the target database, or through your migration tool or DACPAC pipeline.

6. Debug calls from your application. When the bug only shows up when the app calls the procedure, add the SpDev.Runtime NuGet package to the .NET app and use SpDev: Attach to Application: the debugger stops in your .sql file when the app calls the procedure.

SSMS, Azure Data Studio and VS Code compared

	SSMS 22	Azure Data Studio	VS Code + MSSQL (+ SpDev)
Status	Supported, Windows only	Retired February 2026	Supported, all platforms
Write and run T-SQL	Yes	Yes	Yes
Execution plans	Yes	Yes	Yes
T-SQL debugger	No (removed after 17.9.1)	No	With SpDev
Line-by-line procedure profiling	No	No	With SpDev Pro
Server administration	Most complete	Partial	Partial

Moving from Azure Data Studio

• Connections: re-create the ones you use as MSSQL connection profiles; they can be grouped, and passwords are kept in the operating system’s credential store.
• Notebooks, extensions and other Azure Data Studio-specific features: check each one you rely on before the move. Most Azure Data Studio extensions have no VS Code version, and the Azure SQL Migration extension was retired with Azure Data Studio.
• Keyboard shortcuts: Azure Data Studio was built on VS Code, so most shortcuts are the same.

The switch takes an afternoon. The bigger benefit comes later: procedures in source control, tested from their files, debugged and profiled in the same editor where you write the application code that calls them.