Reverse your thinking. Think of a business that's dependent on MSSQL -- now they can run in on Linux, and also, they won't need to think about DB server migration. Many businesses are gravitating towards Linux on the server for many reasons, but they don't necessarily want to change their DB technology.
In other words: MS isn't just trying to acquire new users, it tries to keep existing ones.
This 10x. We're a very large consumer of MS licenses, and even so, we're pushing out to Linux where we can. And of all the MS technologies we use, the one we'd never give up is MSSQL.
I couldn't agree more here. SQL Server is the only server product from MS I won't move off. I'm running an MS server only to run SQL Server. I would love to use a linux instance.
Reverse your thinking. It's not about enabling people to move to Linux while keeping not ms sql. It's about making sure the people who are moving to Linux either way don't also move away from ms sql
The query planner is top notch. I rarely have to worry about query plans. MSSQL will take my 'readable' code and make an efficient plan out of it. Whereas in mysql and postgres there are many times when I have to write less readable SQL code because their query planners are not able to optimize as well. Ex: mysql sometimes has issues with nested statements, and postgres has fences on CTEs.
I read this while I'm right in the middle of trying to figure out why a linked server query which is a simple join on the same table, on two indexed columns, is taking 5 seconds.
I'm not saying MSSql isn't really nice. I'm just saying I found the timing of reading your comment amusing.
> To create the best query plans when you are using a table on a linked server, the query processor must have data distribution statistics from the linked server. Users that have limited permissions on any columns of the table might not have sufficient permissions to obtain all the useful statistics, and might receive a less efficient query plan and experience poor performance
I'm honestly not sure how much of that would be related to the query planner vs linked server network code.
Speaking of which, linked servers (cross OS, cross SQL type database queries) are native in MSSQL, but require a third party odbclink in postgres, which does not appear to have been updated since 2010[0].
Linked servers in Postgres can be implemented using foreign data wrappers (part of the SQL/MED implementation in Postgres - MED = management of external data which is actually in the SQL spec):
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
but stuff like "Does not compile with PostgreSQL >= 9.2!", "A patched, but completely untested version", and "The current version does not yet support WHERE clause push-down, column push-down, JOIN push-down, or write operations."[0] are riskier (and a harder sell to management) than having the functionality backed in the core engine and admin interfaces.
Up to a point.
Unfortunately this fairly rock solid planner means that a lot of people will keep throwing things at it until until explosions.
SQL Server's parameter sniffing often makes me sad, and having to turn on trace flags effectively by default is still fairly annoying.
In most of the benchmark contests I've seen SQL Server does pretty darn well - and if you don't mind locking yourself into the domain, it comes with a lot of bells and whistles for ETL and stuff (SSIS) - and it's been a few years since I was a DBA, but at the time nothing came close - even close - to SQL Studio as an IDE. I'm not saying I'd pick it over PostGRES hands-down, but there are a lot of things going in its favor that merit at least basic consideration.
SQL Server on a virtual Windows server is like the de facto set up within the non-IT-but-still-kind-of-technical groups of large organizations. There's just a ton of UI tools built for it and it's a nice transition from Access to something more robust.
But it means having a separate windows-server team set up to handle builds and all that. The crappy thing is that the rest of IT uses Linux or Unix based OSs for their software, so Cygwin ends up getting installed on most Win Servers to open them up to the NFS shares that drive most of the data movement. I could see this being pretty huge to be able to migrate the various SQL server versions and Win OS versions over to Linux and ditch the need for dual environments while still supporting a RDBMS that most of the business is comfortable using and has tons of legacy data and apps built against them.
But.. yea I agree. If you just need a database, drop Postgres on a linux box and role. It's free and there is a huge community. If you've got the money and need something managed for you with support built in and lots of horsepower then go with something like Teradata. SQL Server feels like the Sears/k-mart of RDBMS. I'll just go to Walmart, thank you very much.
You might have an application that uses SQL Server-specific features, and if you have a separate database server cluster now you just have to pay for SQL Server licenses instead both it and Windows Server.
It makes sense to charge different for different OS. Using absurd examples, it would not make sense to charge the same for a hypothetical version of SS for iOS than say another hypothetical version of SS specialized for CoreOS for instance.
Presumably you're not going to start using it now if you haven't been already. But if you are looking for a more flexible deployment target for your existing SQL Server setup...
Because a lot of software vendors use SQL Server for their backend, so now you can have a choice to run on Linux. It is major league annoying to have to use Windows Server if your backend is mostly Linux, etc.
I dearly hope the SmartOS and FreeBSD folks can make it work on their respective platforms.
For example you are running an ASP.net+MSSQL app and you are tired of dealing with IIS and/or Windows Server. Now you can run Nginx+ASP.net+MSSQL on Linux, for minimal effort.
