I got this question recently from someone that was evaluating the SQL Change Automation client in Visual Studio. After setting up a new PoC (Proof of Concept), they were confused about why there is a new entry in their list of SQL Servers.

If you’re wondering, this is what you see in Visual Studio 2017, for the SQL Server Object Explorer.

In my case, I’ve actually got a few different instances since I’ve been working with the SQL Change Automation (SCA) for years, across a few versions.

As the instance names list, these are LocalDB instances. LocalDB is a version of SQL Server that is spun up in process, rather than a service. Other than that, it’s a real SQL Server instance that is running. In fact, if you want, you can connect to this with SSMS.

If I connect with those credentials, this will appear in the SSMS Object Explorer as well, the same as any other instance.

Why is this in SCA?

As an early part of the SCA product, when it was in ReadyRoll, there was a desire to not impose burdens on application developers. If you were working with a project for C# or ASP.NET and wanted to include the database, the idea was to keep things simple.

The simple way to get up and running is to use LocalDB, so no install, no worries with Express and a service running, just use LocalDB. This used to be more of a default, but now it’s just one of the options.

In my case, once I’ve setup my project to connect, the Shadow database, by default, is also right here, and I’ll see both databases under the (localdb)\Projectsv13 instance.

All of this is configurable, so you can set things to work in whatever manner works best for you. If you typically have a development instance, either local or remote, you can easily use those instead, and you’ll never need to worry about LocalDB. In fact, if this bothers you, you can disconnect or even delete the instance.

LocalDB is a lightweight way to work with SQL Server, but you don’t need to use it.