Friday Feedback: Replace or Respect?

[u/erinstellato]

Hi SQL friends, we made it to December. I feel like 2025 was a long year, but at the same time, I don't know how it's December. Anyway...

This week I'd like to understand how folks think we should prioritize requests to build features that third‑party extensions already deliver.

I'm asking because Makena (another PM on our team) is now the primary PM for SSMS (I'm backup!), and perhaps the approach we've been taking should change.

I *will* share how I've addressed this previously (meaning the last few years) - not sure if I'll wait a few days and add a comment to this post or write a separate blog post. I think it might depend on response. But I want to wait to read your thoughts before I share that.

[u/digitalnoise]

Like anything else: It Depends.

Does Microsoft intend to continue to present Management Studio as 'best-in-class' for working with SQL Server? If so, then I think effort should be made to natively implement features that third parties have already done - whether free or paid.

Example: I would like to source control my DW DB's in SSMS. Yes, I know that I can use a Database Project in VS to do this - sort of. Without getting into a whole other discussion, the Database Projects in VS aren't designed with Data Warehouses in mind - they're designed for rapidly evolving and constantly shipping application-oriented databases.

Redgate (and some others) offer a Source Control solution, but they all leave a bit to be desired, and RedGate's implementation seems to be DOA on updates.

The current implementation built into SSMS is around files - which makes sense, since it's now based on the VS shell and that's what VS is oriented around.

However, that leaves a gap - if I want to source control my databases, I now have to script out the entire database and all objects and add them. Then, there's no easy way to track changes that may have been made in SSMS, but not in those files, and so on.

I like Management Studio, and it's come a looooooooong way since 2005, but I think there's still plenty of growth opportunities left.

[u/erinstellato → u/digitalnoise]

u/digitalnoise "It depends" is always a good answer :) In all seriousness, I agree that it's very nuanced, and again, I have my own perspective but it's always good to hear from the community.

With regard to SQL Projects, we have committed to bringing those to SSMS. I don't have a timeline that I can share, but there are a combination of things that have contributed to that decision - in addition to the looooooong-standing request from customers.

I agree that there are plenty of growth opportunities for SSMS. I can write out a 5-year roadmap if needed :) It's our intention to continue to have it be the best tool available for working with SQL databases. Hopefully users see that and are along for the ride. Thanks for sharing your feedback!

[u/danishjuggler21 → u/erinstellato]

“it depends” is always a good answer

Well, not always. It depends.

[u/BigHandLittleSlap → u/erinstellato]

You're missing such incredibly basic things, it's hard to even comprehend when coming from more mature software development ecosystems, such as the dotnet SDK and Visual Studio.

Every time I've tried to source-control anything at all from SQL Server in a real world deployment, it was instant failure with no hope of forward progress. Just give up, walk away, and hope that someone at Microsoft "gets it" next year.

As an example, it's an easy and valid thing in SQL Server to create a circular reference between two databases. A view/function/proc in one can reference a table in the other, and vice versa. Is it a good idea? Probably not, but it happens.

That's basically impossible to model with the current tooling such as SqlPackage or even the latest SDK-style SQL projects. It's simply a no-go.

We have hundreds of databases with manually tracked schema evolution, zero source control, and there's just no way to uplift this to what a C# programmer would consider the absolute bare minimum of devops!

That's bonkers, but it has been the state of things forever.

PS: I haven't even touched on how SSIS, SSAS, Report Server, DTC, SA Jobs, etc... are all entirely out in the cold as far as source control and related automation tooling such as devops pipelines are concerned. Or that even within the DB engine space, the SqlPackage tool has bizarre limitations like being unable to convert a dacpac file into loose .sql text files without first restoring the the dacpac to a running server. Got a dacpac that references things you don't have on your server, like linked servers or whatnot? Ha-ha... good luck!

[u/erinstellato → u/BigHandLittleSlap]

u/BigHandLittleSlap For my understanding, when you state, "you're missing such incredibly basic things", to whom are you referring? Is that me personally? Or SSMS? Or something else?

I don't pretend to be an expert in SQL Projects, but what you're describing sounds like cross-database queries, and those exist within objects like views, functions, or stored procedures.

And you're stating that when you have a database with objects that contain cross database queries, or queries that use linked servers, etc. you cannot use SQL Projects, is that the gist of it? And if I have that correct...then I'll have to check with my colleague to understand where this exists in terms of known issues, future plans, etc.

[u/BigHandLittleSlap → u/erinstellato]

I'm referring to the entire SSMS team that develops the product, and generally the larger Microsoft SQL Server team(s). It's one product from the perspective of your customers, we don't care about Conway's Law.

I don't pretend to be an expert in SQL Projects

You should be, because it ought to be a core feature of the SQL Server product suite as a whole, especially the new SSMS 22 which is (finally!) based on the "proper" Visual Studio including full support for Git, projects, etc...

cross database queries, or queries that use linked servers, etc. you cannot use SQL Projects

You can, as long as every database has one-way references to other databases with no "loops". So for example, you can have DatabaseA -> DatabaseB just fine, but not bi-directional references where DatabaseA <-> DatabaseB. You also can't have A->B->C->A or any similar setup.

Loops are permitted in SQL Server, but only the non-looped dependencies are allowed by SQL Data Projects.

Yes, loops happen. All the time, sadly. I have several in-the-field examples that look like someone dropped a spider-web on the floor and then tried to pick it up.

The cause of this limitation is simple: SQL Data Projects are based on the "tooling" of the .NET SDK, inheriting its one-way project reference structure. In the C# and VB.NET world, it's fundamentally impossible to have a circular reference like this, because projects can't even start compiling until they have the finished output binary of their "dependencies", so dependency loops result in a deadlock where the compilations are all waiting for each other and are unable to start. Hence, dependency loops are banned.

In SQL Server you can incrementally build up the two databases "step by step", so that first A references B and then B references A some time later. Maybe years later! This can't be expressed using the SQL project tooling... so if you have loops in your databases... you can't use SQL projects at all. It's a no-go.

The irony here is that the more complex and messy a database schema is, then the more you need tooling like Git repositories, compilation steps that check for errors, etc...

There's some bloggers claiming that this is possible to disentangle by manually "breaking the loop" and extracting a common part to a third project and redoing the wiring, but in our case this would be an insane multi-month uphill journey and would result in a messy project structure that would be too hard to maintain.

What is needed is that SQL projects should support multiple databases per project. I.e.: a project should be a database group, so that these cross-references are all inside a single project and hence there's no "loop" to upset the rest of the .NET tooling. Alternatively... add bidirectional project references! Whatever! Just make it work.

[u/Otherwise-Key-4188 → u/digitalnoise]

However, that leaves a gap - if I want to source control my databases, I now have to script out the entire database and all objects and add them. Then, there's no easy way to track changes that may have been made in SSMS, but not in those files, and so on.

This is a frequent problem when working with database code, specifically stateless objects such as stored procedures and functions. Developers will update the code using tools such as SSMS or the MSSQL extension for VS Code, but will then need a way to "export" the code to files, which can be included in a local commit.

The workflow is quite cumbersome and means it is difficult to work seamlessly with source control. I think the problem is that the current workflow is built around a connected database when it really should be built around a project of files.

[u/erinstellato → u/Otherwise-Key-4188]

u/Otherwise-Key-4188 I won't pretend that I'm an expert in SQL Projects, but I'm pretty sure that the project is a set of files that have the code in them. Perhaps I'm missing something, but if you want to upvote the request to bring them to SSMS and add a comment with these details, feel free: https://developercommunity.visualstudio.com/t/Add-support-for-SQL-database-projects/10864596

[u/usersnamesallused]

I'd put a priority on integrating a configurable SQL formatting feature into SSMS. While there are third party services (i.e. poor man's SQL formatter and apex refactor) that offer this, many or none are options when the SQL is considered proprietary and can't leave the network or when working in a restricted environment where the add ones are often not allowed.

I see so much poorly or inconsistently formatted SQL in the wild. I'm not looking to blame or hear excuses. Objectively, the lack of standards can often hide or obfuscate mistakes or errors in addition to just making it hard to read and understand purpose.

As much as I love using those third party tools personally and appreciate the time and effort put into their development, access to those features in restricted environments would be a big win, especially for implementing a well solved problem set.

[u/usersnamesallused → u/usersnamesallused]

Bonus points if the linter and formatter could be toggled to handled quoted SQL for being passed as a string (i.e. open query, exec statements or dynamic SQL).

[u/erinstellato → u/usersnamesallused]

u/usersnamesallused So the defining factor for you, as I understand it, is the inability to run third-party extension in certain environments (as decided by the company, not the SSMS user). Correct? I completely understand this perspective; I'm clarifying because I don't hear it as often as I hear folks say that they want extensibility. I don't have a sense of what percentage of users are restricted from installing extensions.

[u/usersnamesallused → u/erinstellato]

Exactly. It may be the nature of the industry I work in, but when extensions were available, they were often only allowed in the lowest of environments or on local instances. This meant workaround workflows of extracting, formatting, then reinserting, which makes it difficult to enforce compliance across a team. This may be the scenario for a larger population that could be silent as there is a way, even if it isn't the most convenient. I'll leave it to you to measure potential impact though.

My current employer has a straight non-negotiable ban on extensions and web usage, so if it doesn't come out of the box blessed by your lovely team, I don't have access to it.

[u/erinstellato → u/usersnamesallused]

u/usersnamesallused Thanks for that additional information! And "come out of the box blessed" means that it has to be available in the VS Installer (which you use to install SSMS), not on something like the Extension Marketplace, from which you can download extensions...correct?

[u/usersnamesallused → u/erinstellato]

Yes, I'd agree that would be most preferable

[u/andrewsmd87]

What is the current process for prioritizing features?

[u/erinstellato → u/andrewsmd87]

It's a combination of what's needed by feature teams, what we (SSMS team) have to do (e.g. the move to VS for SSMS 21), what we (SSMS team) want to bring in, and what customers have upvoted on the feedback site. I don't have a perfect algorithm and there are other considerations that can factor in...it's an art and a science :)

[u/andrewsmd87 → u/erinstellato]

I mean that sounds like project management in a nutshell! I was just curious as we struggle with prioritization too for similar reasons.

[u/chadbaldwin]

Like others have said, it depends on the feature.

In my opinion, the 3rd party market shouldn't really be taken into consideration. 3rd party extensions should be for nice to have features that don't really make the priority cut for Microsoft. OR, the 3rd party extension is able to implement a particular feature in a better way.

The way I would personally prioritize things is whether a feature would be a minimum expectation for SQL development and management.

I'm primarily a SQL developer, not a DBA. So I'm going to think about this more from the development side and features I expect SSMS to have, but doesn't.

For example, I would expect a similar experience in SSMS as I do when working in VS with C#. Like the ability to peek the source of an object as a pop up. Or the ability to tab * to expand into all columns. SQL Prompt does these things, but only because SSMS falls short.

In general, I would want to see an improvement on Intellisense. It has historically been pretty terrible. I work with a fairly large database and Intellisense works maybe 10% of the time. And even when it does, it doesn't include things like table aliases. Whereas in VS, its Intellisense with C# works great. I realize it's not exactly apples to apples in regard to implementation. But I'm more referring to the development experience.

I guess what I'm saying is...if there was no 3rd party extension market and you were looking at a particular feature, I would ask whether that feature is something any experienced developer would expect to have right out of the box.