Despite everyone saying SSMS is hands down the best database IDE, while this may be true it is also true that MSSQL tooling is a train wreck compared to what it could be. It almost seems Microsoft intends to keep it this way, perhaps because they'd have to finally admit to the decade of neglect? Who knows the exact reason, but it's a sad situation.

What kind of tooling are you speaking of? Honest question.

Sql Server Reporting Services is great but the server website was obviously mid-2000s until very recently, even containing markup that wouldnt render in Chrome.

SSIS is a hellscape of unnecessary designers for an ETL framework, and generates ultra-brittle packages that crash if the slightest schema tweaks happen.

SSDT stores your schema and publishes diffs for easy deployment, but will gobble up all your RAM for half an hour to compile... if it doesn't crash.

And SSMS has the worst tabbed interface ever for managing queries.

I agree with you on all points. Products on the periphery of SQL Server have been severely neglected for years. There is a replacement for some of SSRS in PowerBI and SSAS, which is actually pretty nice. If I'm not mistaken, people serious about version control and deployment in SQL Server use redgate software.

My question is how other databases fare in these areas. I'm not familiar with any solutions for Reporting UI, ETL, and Schema Version Control in MySQL or PostgreSQL. What built-in tools do other databases have that outperform SQL Server's (obviously crumbling) functionality?

The general consensus is usually that this MS tooling, yes the one just described, is very good! Certainly far better than the competition. It boggles the mind.

>Simple "Export the results of my query into an INSERT statement" is a moronically obvious workflow and is non-existent.

I've only used SSIS for a few months now, but wouldn't this just be a simple Data Flow Task for that. Now, I'm not saying I would use SSIS for that (because I frankly hate SSIS) but it is a trivial thing to do.

I've never been able to match bcp's speed when importing large amounts of data, though.

I've never had an import job where run time was a key concern... but the old ADO.Net Bulk Insert thingy has always been good enough when Entity Framework was too slow (which, for inserts, it generally is).

How large a job are you talking? Did you use a transaction? A transaction + being in a nearby location has been good enough for every import I've done (millions of rows).