We can agree to disagree, but the tooling has definitely saved me enough time to be worth it. That and realistically, no matter the DB chosen, you either use DB specific features or leave performance (often substantial) on the table.
> We can agree to disagree, but the tooling has definitely saved me enough time to be worth it.
What specifically are you referring to (regarding tooling)? Do you mean running it on Azure as a managed service that auto scales, programming tools/frameworks like LINQ, or client side GUI tools?
From an automation perspective not having a decent CLI for MSSQL to facilitate scripting makes it a pain from day one.
SSMS is pretty great, especially for digging into query plans and deadlock graphs. Same for SQL Server Profiler.
We use Database projects in Visual Studio, so all our schema, stored procedures, and other scripts are in version control. We can compile them (additional validation) into dacpac packages, and script updates and deployment to local instances and Azure with sqlpackage and sqlcmd.
The one real downside here is that you're tying your users to Windows. If you had a more "pluggable" db layer, they could use the platform of their choice.
That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.
