[snuxoll]

> PG just doesn't have the same quality SQL-dialect or tools as MSSQL though.

T-SQL sucks, I don't know how on earth you get the feel of "quality" from it. Every time I have to work with it I cry, pl/pgsql is a hell of a lot nicer and I can feel comfortable stating that as an objective.

As far as GUI tooling? Ya got me there, even as terrible as auto-complete is in SSMS it's leaps and bounds better than PGAdmin or DataGrip for pointy-clicky DBA tasks - though I've just learned to use the system tables/views in PostgreSQL like I have MSSQL because I can't stand pointy-clicky stuff.

> Some very basic facilities are missing from PG like snapshot and transaction logs

What? Snapshot isolation is available by default with PostgreSQL, it ONLY uses MVCC for transaction isolation. You want snapshot, set your transaction isolation level to REPEATABLE READ. And transaction logs? What on earth do you mean? Transaction logs are fundamental to PostgreSQL like they are any other RDBMS, you can ship them off for backups, do PITR with them, etc - just like you can SQL server.

> batched triggers

Yup, that's true.

> being able to return multiple resultsets from a single trip to the database server.

Technically doable with stored functions in PostgreSQL, though ill-advised. SQL Server makes this easier if you need it, for sure.

> there's nothing like SQL Server Data Tools.

Yup, although this is really down to a matter of preference. SQL Server Data Tools is great for warehousing projects, but for application databases using the database migration tools provided by your framework of choice work just fine.

And hey, I've got respect for MS SQL Server, it's a well-performing, well-supported enterprise SQL database - not to mention SQL Server Analysis Services kicks some serious ass for business intelligence use-cases (especially considering it's included right in the package, and with the new PowerBI-derived Reporting Services you get a full BI package for a really good deal). But let's make sure we're all educated on tools before we start nitpicking them, eh?

[Neckmeats]

How about some features that really matter for an enterprise... compare the differences of HA options between PostgreSQL and SQL Server. Or maybe something a little more simple like point in time recovery. Backup and recovery is probably the most important feature of an enterprise RDBMS, and I'm sorry, but PostgreSQL doesn't cut it. It's really fun to develop on, but it's an absolute nightmare to administer. That makes it a liability.

[anarazel]

Think there's plenty of missing tooling around postgres. But what are you lacking in backup with http://www.pgbackrest.org/ ? Or is it just that it's a separate package?

[Neckmeats]

The point I was making is the lack of easy to use native features to perform typical administrative operations. When all is said and done, you may end up with a multitude of 3rd party tools to achieve feature parity with SQL Server , which is the particular comparison, and would be a limiting factor to implementing the platform in an enterprise that cannot withstand down time or tight RPO/RTO requirements.

In regards to SQL Server on Linux, I have just spun up (for testing) a three node AlwaysOn cluster with Pacemaker/Corosync, which is working quite well. Failover works as expected, however it is a tad slower than a Windows Failover Cluster. First impressions are very good and I would not hesitate to recommend the solution over a PostgreSQL or MySQL implementation. It is far less complicated and provides excellent HA and recoverability options.