RedGate

Redgate SQL Toolbelt over Microsoft SSDT: My Biased Opinion

Bob Walker

• 3 min read

Back in the article How Redgate Helped Define our Process, there was this small blurb about SSDT:

Microsoft SSDT Tooling Considered - the increased cost of licenses forced us to take a hard look at Microsoft's SSDT tooling. Could it do what Redgate did? Could we build additional functionality around it? In the end, the answer was no, but that delayed us as well.

I was sent an email asking for further clarification on why Redgate was chosen over Microsoft SSDT. The email mentioned the answer might be a good post. And you know what, they're right, it would make a good post. Hence this post.

Before I dive too deep into this post, let's get the elephant in the room out of the way. Both Microsoft's SSDT and Redgate's Toolbelt can be used to automate database deployments. In fact, they both follow the same core concepts. A database schema is packaged up, .dacpack for SSDT and .nupkg for DLM Automation, and deployed to SQL Server (or Azure SQL Server if you are using PaaS).

The difference is the user interface used to kick off this process. Microsoft SSDT is a Visual Studio plug-in. Redgate's SQL Toolbelt provides many different tools, including SQL Source Control which is a SQL Server Management Studio (SSMS) plug-in. Having a SSMS plug-in makes all the difference in the world.

Let's break down a typical workflow for making a SQL change using Redgate's SQL Toolbelt, let's say creating a new stored procedure to search for customers.

  1. Open up SSMS and write the SQL for the search. Verify results, adjust the query as needed.
  2. In SSMS, create a stored procedure using the SQL created in the previous step.
  3. Add the necessary .NET code using Visual Studio to call the new stored procedure.
  4. In SSMS, Adjust stored procedure until it runs as expected.
  5. Using SQL Source Control, check in the new stored procedure to version control.

That is just the process. Redgate's SQL Toolbelt provides a very nice user experience. It allows developers to keep using SSMS to make database changes and check those changes into version control. It constantly queries the database to check for any uncommitted changes. It provides a visual notification when an uncommitted change is detected.

Let's evaluate the same process using SSDT.

  1. Open up SSMS and write the SQL for the search. Verify results, adjust the query as needed.
  2. In Visual Studio, create the new stored procedure in the database project
  3. Publish database project to development SQL Server (ideally you would be using a local database for this!)
  4. Add the necessary .NET code using Visual Studio to call the new stored procedure.
  5. In Visual Studio tweak the stored procedure.
  6. Re-publish stored procedure to database
  7. Repeat previous two steps until it runs as expected.
  8. Check-in changes to version control.

See all the switching back and for between Visual Studio and SSMS? That is the reason why I prefer to use Redgate's SQL Toolbelt over SSDT. I get to keep using my preferred tool, SSMS, to interact with the database. Yes, sure I could use Visual Studio's database functionality to run queries. It works, but it feels very, very weird to use. Let's use a simple example. The keyboard shortcut to execute a query in Visual Studio is Control+Shift+E. In SSMS it is F5. In Visual Studio F5 kicks off the debugger. Running queries in Visual Studio felt like steering my car with my knees, yeah it is possible, but nothing about it is right.

Learning how to automate database deployments is tough enough, there is a lot of cheese being moved around. That was a given, and I accepted that. That being said, those changes were occurring on making deployments easier and faster. But don't counteract all that goodness by having me relearn how to make database changes.

All that above is my opinion. When I have had the chance to present a choice between Redgate's SQL Toolbelt and SSDT, Redgate's SQL Toolbelt is picked the vast majority of the time. When you think about it, it makes sense. People don't like change. Developers could probably make the switch. They would grumble about it the entire time. But it is possible. They are familiar with Visual Studio. It is a completely different conversation for DBAs, DB Developers, and other roles whose primary responsibility it is to interact with the database. Convincing them to give up SSMS, a tool they have used to do their jobs since SQL Server 2005, to an inferior tool for interacting with SQL Server, is rife with problems.

A counter argument I have heard time and time again is, SSDT is free while Redgate's SQL Toolbelt costs a lot of money. I go into great detail why that argument doesn't hold water in the section "The tooling is too expensive" section in this previous article.

Friction is the enemy for adoption for a new process. It is impossible to completely remove it, but it needs to be reduced as much as possible. If friction is high then a new process will be adopted even more slowly, or it will be abandoned altogether. If SSDT were to become a SSMS plug-in then it would be worth another look. But until then, the friction of adopting SSDT is too high compare to Redgate's SQL Toolbelt.