[mindcrime]

No, almost certainly not. Why would I use MSSQL in the first place, when I could just use PostgreSQL? The main reason I could see to use MSSQL would be "you're in a Windows shop already", and if that isn't the case, I don't see much reason for it.

[manigandham]

MSSQL is fast. It's seamless to use with .NET code and it has several features like columnstores, in-memory tables and graph processing that are very useful. Also availability groups are much better than Postgres solutions for high availability today.

[james_anderson]

I really like AGs but I'm not sure I will love them on Linux. It still feels like it's early days for SQL Server's HA on Linux.

[manigandham]

That's true, although I'm looking forward to a far easier AG setup without Windows Clustering now.

[arethuza]

In my experience, the main reason why most organizations run things like SQL Server or indeed Oracle is because they want to run applications that depend on those particular databases.

[lmm]

Sure - but it would be weird for an application to depend on SQL server and not depend on Windows, and if you're going to be running Windows for some of your servers anyway it's easier to use the same platform for all of them.

[beefhash]

There are some .NET Core programs that also depend on SQL Server but not Windows necessarily. Bitwarden[1] comes to mind.

[1] https://help.bitwarden.com/article/install-on-premise/

[hungerstrike]

I would have said the same thing if I had never used MSSQL.

PG just doesn't have the same quality SQL-dialect or tools as MSSQL though. Some very basic facilities are missing from PG like snapshot and transaction logs, batched triggers and being able to return multiple resultsets from a single trip to the database server.

Even the free tools for SQL Server are better than anything you can get for PG and there's nothing like SQL Server Data Tools.

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

[fulafel]

You can return multiple result sets using a sproc or a view.

Triggers sound strictly less powerful in SQL Server since "for each row" semantics is missing?

Meanwhile there are many PG features missing.

[snuxoll]

> Triggers sound strictly less powerful in SQL Server since "for each row" semantics is missing?

Triggers in MS SQL are batched, you get "for each row" semantics by iterating over the contents of the virtual "inserted/updated/deleted" tables. This is honestly a pretty sane design choice, it helps trigger performance immensely when dealing with bulk data manipulation since you can do things like JOIN's on the whole set of triggered data allowing the execution engine to do one index scan or hash join instead of a bunch of index lookups on individual rows. Ironically, after doing salesforce.com development for a while this is one of the things I really wish PostgreSQL offered.

[fish_fan]

How is the JSON integration and geometry primitives? I had no idea it was competitive with postgres.

[snuxoll]

"JSON" in SQL server is a set of functions layered on top of NVARCHAR(*) columns, so - about where PostgreSQL was when they first introduced the 'json' data-type.

Can't say I've investigated the geometry types, but at a glance they're functional (if uglier to work with).

[jenkstom]

Then again, T-SQL is a developer's nightmare. Especially when compared to PostgreSQL's version of SQL scripting. And when you add on all the supported languages it makes MSSQL quite painful from a SQL developer standpoint.

[Neckmeats]

This sounds like more of a religious issue than anything. All of the dialects of SQL have pros and cons, but if you stick as close to the ANSI standard as possible, the differences are negligible. If today's developers actually cared about relational theory, and spent the time to do it right, they wouldn't really care much of the difference between T-SQL or any other dialect. Like when developers bring up a platform preference based on JSON data type support... you're doing it wrong to begin with.