MSSQL's really not too bad. Yes, it's a commercial offering, but there's nothing inherently evil about charging money for software, and you do get what you pay for.

I've worked in both MSSQL shops and PostgreSQL shops, and, while I wasn't in charge of the budget, I wouldn't be at all surprised to find out that, once you factor paying your programmers and DBAs for their time into the equation, the MSSQL shop ended up having lower overall costs associated with its choice of DBMS.

Have you worked on MSSQL licensing in the age of Virtualization and per-core licensing? It's gotten VERY complex according to some of my friends that still run it.

It seems they have changed their pricing strategy:

    Oracle: What is your IT budget? We'll take it. (all of it)

    Microsoft: Hey, at least we're not as bad as Oracle.

MS licensing is somewhat expensive, but easy to understand and relatively benign. Oracle licensing chokes you like the Drakh keepers from Babylon 5.

I'm currently working on a mssql shop, and on aws it's more than twice the price vs postgres or aurora. I don't see how you can justify the price difference

I'm not sure I follow this logic. Wouldn't both databases require the same amount of care and feeding? Are you suggesting that you need less DBA's per MSSQL database than for a PostgreSQL or Maria database?

Yep. Because the tooling is stronger. The developer ergonomics are better. The performance is better, meaning you'll be able to do more with fewer servers. MSSQL has a boatload of useful features that PostgreSQL lacks. (Clustered indexes and table-valued parameters are the ones I like to fixate on.) And so on. I can only personally speak to the developer story, but my experience has been that the productivity difference is huge. There's a night and day difference in the information you can get out of an EXPLAIN on each of them, for example, and I would get detailed emails warning me if a MSSQL query plan unexpectedly changed in production. With PostgreSQL you're more likely to need to build your own tooling for that sort of stuff, or just wait for a user to complain. On the DBA side, I'm hazier on the details, but I've seen PostgreSQL DBA's sinking hours' or sometimes even days' worth of effort into grinding through tasks tasks that an MSSQL DBA can bang out by spending a couple minutes clicking through a wizard dialog.

If you're a tiny startup, the differences won't amount to all that much, and it will be hard to justify MSSQL's price tag, which is fine, because, yeah, you can't afford it, anyway. If you're an enterprise or otherwise have large database needs, the differences can very quickly become apparent, and easily worth the money.

I have worked with both databases over a decade. The biggest difference between SQL Server and Postgresql is neither tooling or performance(both are excellent), but the community and culture.

By far, PostgreSQL has more knowledge sharing and documented edge cases. Not to mention that the official PostgreSQL documentation is probably one of the best documented software systems ever. This makes PostgreSQL a lot easier to learn and use and that also affects the amount of money you need to spend.

SQL Server has some annoying edge cases, licensing is a real pain point these days, but so are the technical issues like lack of schema support in the JDBC driver. Other things are that you cannot pipe the backup. I would love to take backup of an Azure SQL service to my local machine with SSH.

Instead of a table-valued parameter, wouldn’t you use an array of a composite type in PostgreSQL? What are the relative good and bad points?

Yeah. And you don’t need to create a custom type to handle it as a parameter. So it’s easier.

The only thing SQLServer has over PostgreSQL is multiply resultsets. That’s it. I really wish that existed in PostgreSQL to prevent round trips.