> I feel like rewriting this on top of SQL Server Express

Why choose a proprietary engine? Why not use PostgreSQL or even MySQL?

I can recommend HeidiSQL, a useful GUI for MySQL, MariaDB, MSSQL and Postgres. https://en.wikipedia.org/wiki/HeidiSQL

They probably meant SQL Server Compact, which is a smaller package and comparable to SQLite. It was meant to power WinFS back in 2006. But it's closed source and now legacy.

https://en.wikipedia.org/wiki/SQL_Server_Compact

There are many business applications that target SQL Server exclusively.

On the one hand, I find that highly annoying. On the other hand, even if you don't like Microsoft, SQL Server is fairly awesome, performance-wise and stability-wise.

But still, there are many applications where you cannot really choose what database engine you want to use.

I suppose PostgreSQL+FDW would be just as good as SQL Server Express+Linked Servers technically. You end up trading users' MSSQL experience for pgsql.

I wonder if it would be easy to support both backends and be able to switch between them depending on the query and which features and integrations you want.

> Also, SQL Server is awful at importing/exporting data directly. Almost all forms are broken in various ways and are a source of endless grief. The only reliable built-in way is to use SSIS which is like using a 200-ton tank for a paperweight.

So much this. BCP is inferior to 5 lines of C# code, the tools for importing and exporting data in SSMS are buggy and cumbersome, SSIS is a gigantic monster. Simple "Export the results of my query into an INSERT statement" is a moronically obvious workflow and is non-existent.

I've read that the tools division of MSSQL was running on a skeleton crew for a long time, and it shows.

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).