As someone who has been working with them on pushing this live for the last 6 months I can tell you, we're all very excited to finally push this public preview
I signed up early on as I have an old OSS project that supports MySQL/PostgreSQL and MSSQL. I had originally tried to set up a full CI environment using Vagrant, but automating the Windows/SQL part became so much of a pain I gave up on it.
I'm really thankful that they released Docker containers!! I was planning on moving the entire CI system to Docker anyway and this totally fits in, plus it's super easy to accept the EULA and run the evaluation container.
The linux tools seem to rely on a custom version of unixODBC. There is a binary rpm on the microsoft repo, but no source rpm. This seems to be contrary to the unixODBC license.
It's just the relational engine for now, no SSIS, SSAS, or SSRS. If you want to see more capabilities on Linux, I'd open a Connect item or search for an existing one and share it back here so people can vote.
sudo apt install mssql-server felt really weird. Oddly a much nicer install process than the last time I installed MSSQL server on Windows(which was admittedly a log time ago, and it could be better now).
Installing SQL Server on Windows still sucks, though with your CM tool of choice it's less painful (still takes a flipping century to install, however).
SQL Server 2016 on Windows 10 was fairly one click install when I did it a week or so ago. It was infinitely better than my experience with SQL Server 2012, which was a struggle at the best of times.
That's odd given how easy it is to shim the Linux/POSIX socket API - most of it anyway - on Windows. I made good money back in the day by writing server software that had to compile and run on both Windows and Linux (actually it was never deployed on Windows, but on an embedded Win32 compatible OS, but they were planning to move to Linux, so I did all development on Windows, tested on whatever embedded platform they used and Linux) - the "compatibility" layer was a few dozens of lines in a header file.
The bigger news and unfortunatly hidden behind an innocent blog title about SP1 for SQL Server 2016 is that now all the features of Enterprise Edition are available on all editions of SQL Server!
They haven't made all of the Enterprise Edition features available on all lower editions, but they have made many big ones such as table partitioning, Always Encrypted, in-memory OLTP, etc. available in most lower editions. There are a number of operational features such as piecemeal restores, Resource Governor, online index rebuilds, etc. that are still exclusive to Enterprise Edition.
Not quite all features. AlwaysOn Availability Groups is still limited to two hosts in Standard, and Standard still doesn't have Transparent Database Encryption.
There will undoubtably be a number of good responses here to your question, but I'd like to share my opinion. For me, the answer comes down to tooling. I make frequent use of Integration Services, Reporting Services, the Server Agent, Profiler, and other services I'm not remembering at the moment.
In my mind, SQL Server represents an ecosystem of tools and services that are simply part of the package (no additional cost) and are fully supported and integrated as part of a comprehensive suite.
I love pgsql and it has some features that SQL Server does not, but SQL Server also has a range of features that pgsql does not including index-organized tables, automatically-updated materialized views, much more mature support for query parallelization, etc. Lots of the discussion in this older thread is still relevant: https://news.ycombinator.com/item?id=9464505
If they ported query parallelism across CPU cores as base MSSQL on Windows has, that would be a significant differentiator for those in the DWH / analytics space.
Its also likely this is a attempt to keep customers on the MSSQL platform who otherwise don't have a need for a commercial OS, and may be willing to keep paying for MSSQL while cutting their OS expenses.
This doesn't seem to be a bona fide port to Linux. The sqlservr binary seems to load some .sfp files in the lib directory of the installation, and those files seem to include a good chunk of a Windows installation. There's registry hives, batch commands, and what look like PE64 executables in there.
MSSQL is basically an OS of its own, and does a lot of things in its sandbox that you'd normally expect OS to provide (like really low-level memory management and I/O, and I think even threading is heavily customized) - and that's on Windows. So it wouldn't be surprising if that is the case on Linux also.
> all SQL Server users — including those using free edition — will now get access to the developer features that were previously restricted to the Enterprise edition.
This aspect is interesting. What I haven't done since all of these open source and cross-platform moves by Microsoft is go back and figure out how tech costs scale with user growth (starting from 0). It used to be no contest (initially), but I'm not sure anymore.
I'm not sure what it means. Do you have no restrictions on developer tools only or do they remove the 10GB database size restriction for SQL Server Express, the free version.
Lots of previously Enterprise Edition-only features such as table partitioning and data compression are now available in Standard, Web, and local editions. This is a pretty big deal. More detail here: https://sqlperformance.com/2016/11/sql-server-2016/big-deal-...
I can still remember an old conference when Microsoft bragged that running windows-only allowed them to remove 20-30% of the Sybase code base as they didn't need the cross-platform cruft.
It would be interesting to see how they code for cross platform portability now.
If I understand correctly, this is not even a compatibility layer like Wine. This is literally a part of the Windows kernel and userspace, running entirely inside Linux userspace.
That was probably both true, and slightly misleading. I remember a talk on Drizzle (a MySQL fork looking to clean up and streamline the system after Oracle's buy) years ago where they touted similar numbers in code reduction by dropping support for all non POSIX or edge case OS's other than Linux, FreeBSD, and OS X (and that last one might have been added later). That is, they ripped out the HP-UX, AIX, Solaris and Windows specific code (and possibly more). Sybase looked to support a similarly diverse group of operating systems[1], so there were probably a lot of gains to be had even if they didn't remove all POSIX support.
IIRC, they have since adopted an OS/FS shim to be able to make porting like this generally easier... that said, there are certainly a lot of edge case features that need to be tested... I'd be surprised if there wasn't an effort to bring an electron based Management Studio for cross-platform usage. Which would be pretty damned cool...
The `tedious` package in node, makes it a drop dead simple db to use cross platform... Compared to say the beast that is Oracle, I haven't used db2 from node so can't compare there.
Looks like there are some (most?) unsupported features external to core DB engine ATM (replication, mirroring, agent, SSIS etc. ), but documentation says "The support of these features will be increasingly enabled during the monthly updates cadence of the preview program". Nice.
This is great news and I am looking forward to be able to use MSSQL from within linux and macOS. Hopefully the client support is going to be cross platform too.
The one thing in the article that puzzled me is:
Thanks to its support for Docker containers, even macOS users will be able to run it.
Indeed, Microsoft is betting on containers as one of the main distribution mechanisms for the preview
Wasn't there a golden rule to not store persistent data in a container? I can see it being useful for testing, but am wondering if this is going to be suggested for deployment as well.
Of course one can locate the database on external block storage, but that makes it less easy to support due to having multiple parts. (not that that is a very big issue)
> Wasn't there a golden rule to not store persistent data in a container?
You shouldn't store persistent data in the container. However, you can mount external storage and read/write to it from inside the container. The most simple example of this is mapping a path from the host.
It does not persist data. It requires shared volume support for that, and they are not currently supporting shared volumes on macOS, which makes this, for all practical purposes, useless on a Mac.
I have it running in Vagrant, in the meantime. Easiest SQL Server install I have ever done.
Instead of that, I can see them partnering up with Red Hat (and/or Canonical) to handle it. All of Microsoft's "<foo>-on-Linux" offering (i.e. SQL Server, .NET, etc.) will be officially supported on RHEL (and/or Ubuntu), just like many other enterprise-type products today are officially supported only on RHEL.
The only point of offering it would be to support running desktop applications on it, like Word and Excel, no? And that's such a stretch that all the versions of Wine still haven't solved the problem, even after 20 years.
At this point, if Apple really wanted to scrape another percentage of desktop users away from Microsoft, THEY could release an unsupported, white-box version of the BSD-based macOS for generic PC hardware, which would run all normal macOS binaries, like Word and Excel. It would go a long way to shoring up the gap in their lagging "pro" line...
> all the versions of Wine still haven't solved the problem, even after 20 years.
Wine isn't Microsoft, and doesn't have access to Windows internal code. If Microsoft decided to write a Windows compatibility layer for non-Windows OSes, it wouldn't have to reverse-engineer. That is an immense difference in terms of amount of effort.
Is there a ELIF type link for licensing that explains what we are allowed to do with this on Linux? Can I use it for development work on a company owned workstation?
I'd imagine you can just use a free (as in beer) developer license for SQL Server work on Linux, just as you can on Windows. SQL Server licensing is only really charged on production instances.
Microsoft has really adopted an if-you-can't-beat-em-join-em attitude these days. There were times when Microsoft and Linux were at such odds that an announcement like this seemed impossible.
The next smart move I'd love to see from Microsoft is similar to Apple's adoption of BSD as their base OS with the introduction of OSX, an adoption of Linux as the base Microsoft OS. They could stop wasting money on systems programming and focus on the UI and apps which is where they make their money anyway. Wine has come a long way with Microsoft's direct help it could support all of the existing Microsoft apps.
Because NT, as in modern NT, is pretty damn sophisticated. Switching to Linux really wouldn't be a step up for Microsoft.
As I said before, it's the crap that's been bolted on that really makes Windows feel like a dinosaur. It's the decades - literally decades - of backwards comparability, the lack of a proper package management system and the free reign that developers gets that makes Windows a mess. It's the multiple shells that try to coexist or the feature bloat of pass releases or even Microsofts past tendency to reinvent the desktop every few years rather than introduce incremental improvements. This is all issues independent of the kernel, syscalls etc - i.e. All issues Microsoft would have to address regardless of which core they chose to run. So switching to Linux wouldn't help them. If anything it would just make things worse because they would forgo the stable graphics ABIs in NT for the uncertainty that is Linuxes display server wars. They'd forgo their stable Win32 APIs and other libraries for WINE. They'd have to reinvent DirectX - who's support in WINE is several generations behind - and have to battle with the appalling state of Linuxes graphics card drivers. And that's just scratching the surface of the problems they'd face.
I do love Linux and find Windows to be a hateful platform, but pragmatically Windows switching away from NT would be the dumbest thing Microsoft could do. NT simply isn't an issue.
I also know that I do not look forward to a world with only one dominant desktop/server OS kernel. We need competition here and Microsoft adopting Linux would ruin that.
I doubt that will happen. There are innumerable man-hours of engineering sunk into Windows, and it has made them lots of money. Unless there were compelling proof that continuing to develop and support Windows was costing them money, and endangering other profitable revenue streams, Microsoft will likely keep Windows alive.
Apart from reducing OS bingo (no need to deploy Windows to run SQL Server alongside whatever non-Windows OS you use to run your apps on), what is the selling point?
I assume it runs on x86 processors. If I do everything wrong and end up needing a ridiculously powerful machine I can check IBM's POWER-based boxes or Oracle's SPARC machines that run MySQL or PostgreSQL (or Mongo or anything else) and scale vertically well beyond the largest Xeon boxes. But those won't run SQL Server. Being that the case, why not Windows?
Windows licenses cost. Also if you are running your other stuff completely on Linux, having to setup Windows boxes just for the SQL Server can be bit inconvenient. I see this as a companion to the multiplatform .NET. Now you can run a Microsoft shop without running Windows.
So how do I add a sql server instance in a container with an average of 300 million rows per table and a db of average size of maybe 3 tb and not have io issues? Containers do not seem to scale to enterprise besides nosql type operations of let's commit later.
Thanks! As of yesterday I was looking to find a way to install it on Ubuntu. I finally chose to use TeamViewer on my home PC but my database didn't connect. I'll try this instead.
Hi mmargerum -
We have a Microsoft engineer contributing to the tedious project now. Let us know what you want to see in our new gitter room:
https://gitter.im/mssqldev/Lobby
no announcement of support for mssqlstudio on other platforms yet though right? still, this is excellent - I love my postgres but having mssql on linux is a great option.
It's commercial, privately licensed software... that said, the out of the box defaults for MSSQL perform better than most databases, with features far easier to configure. I've been hoping for this for a long while... much better for most use cases than Oracle.
