SQL Server on Linux: Canonical offers official support, AWS Babelfish helps users move to Postgres Canonical is offering joint support with Microsoft for SQL Server on Ubuntu running on Azure, all while Amazon is nudging users towards PostgreSQL with general availability of the Babelfish compatibility extension, now open source. SQL Server for Linux was introduced over five years ago and has been generally available for …
SQL Server licensing is expensive…
So are all commercial databases, though the last time I checked SQL Server was quite a bit cheaper than Oracle. But SQL Server's licensing also dictates a lot about the environment it needs to run on and this alone makes it undesirable for anywhere wanting to run multiple instances of multiple databases (dev, test, prod, etc.) because they all need separate Windows Server instances with all that entails.
FWIW there's a "developer" edition. It is fully featured and free of charge but has license clauses forbidding using it for production. Switching between the different editions when you run SQL Server on Linux is IIRC just a case of changing some config.
I think the idea is to refrain from nickel-and-diming you for the tiny DB instances you spin up during dev and QA, to maximise the chances that you get your software all the way up to ready for production deployment without being exposed to sticker shock. Then once you go live they can really whallop you in the pocket for full-scale database servers in production. ;)
That's express editions. If they embedded developer editions with their applications, they would get into trouble. Developer editions have the same limitations as the different retail versions.
Also to reference your initial post. If you really wanted, you could have multiple instances of SQL Server on the same server, it doesn't cost anymore to have more instances running. You pay for the number of cores the server has, you can then run it how you like after that on that hardware.
unfortunately there are those out there who LOVE the way SQL Server does things. I am NOT a fan of it, and have only used those features that are basic to any SQL database (the idea was to make the code DBMS-independent and do all of the real work in C). That argument was mostly philosophical, and you always had some advocate generating a specialized query using SQL Server specific features (like maybe a stored procedure) instead of something that would work EVERYWHERE, especially an edge case example, to try and make YOUR DESIGN look bad and gain brownie points. Never mind that once you're LOCKED in it's even HARDER to switch to something else down the road.
I'm a fan of PostgreSQL because (in my opinion) it provides an SQL that is compliant with the standards as well as being open source. So something written for PostgreSQL generally should work everywhere, except for when the implementation has quirks (like MySQL or maybe even Maria - string handling with embedded quotes comes to mind - yeah NOBODY has a '1/4" nut' in the description field right? Or calls something "Joe's favorite hammer").
In any case, my own preferences aside, the selling point for Micros~1's solutions is usually something that locks you in later down the road. Then you won't have a choice any more (not without cost at any rate). "Embrace, Extend". You are locked in with 'Extend'. And you know what follows, something that forces you to migrate to something even MORE proprietary and costly... you know, like maybe HAVING to use a Micros~1 server product instead of Linux to run SQL Server on, maybe? With per-seat licensing and/or monthly subscription, of course!
Personally, I use it at work because a) I can run it on any of (Linux, Mac, Windows) inside a Docker container using Docker Desktop or whatever, b) this way I can use `docker commit` to take snapshots and that is way faster than using its backup and restore tools (which also for some reason are/were only available on Windows), and c) also doing things like spin up/down/snapshots are really slow on Azure, whereas the docker containers start quickly enough.
Some of the software we develop runs on Azure and uses the Azure hosted MS SQL Server, so that's why we're using it at all in the first place.
SQL Server backup and restore are painfully slow for development. I don't know why but for some reason they take 30 seconds up to entire minutes of time on CPU to export/import the DDL before they even get to the rows.
The DB backup & restore buttons on Azure hosted SQL Server are incredibly slow/cumbersome. You have to schedule the operation and then wait for a background worker to come along and get around to actually doing the backup/restore (to a blob in Azure Storage). At least 1 time I saw a tiny 5-minute database export take >1 hour to get assigned a worker and start being processed.
yes I can see that you want to use a Linux server, and you are SO correct for doing that, but running Micros~1 SQL Server instead of something like PostgreSQL... THAT is the question *I* am thinking of!!!
I just can't see any REAL reason to use SQL Server instead of "something else"
You have software from a vendor that only supports commercial databases? SQL Server is lot cheaper than Oracle, and if you need one I would rather run it on Linux than windows. You might also have some Sybase databases that you can't get rid of in which case SQL Server license is likely to be again lot cheaper than new ASE license.
If "something else" is supported, then hell yeah it probably is better option.
The article asserts that "differences are not dramatic" between the Windows and Linux platforms, but this does not hold true with a careful observation of TPC-H benchmarks.
Locating the top benchmarks for SQL Server on tpc.org, nearly all of them are on Linux. The few that are on Windows do not perform as well.
My suspicion is that XFS has a great deal to do with this performance.
Ubuntu also runs SQL Server, usually on ext4. An interesting point about Ubuntu is that Oracle offers free KSplice kernel patches for it, so a high-availability OS platform with current patches is possible to obtain at zero licensing cost. The Windows equivalent does not exist.
The performance and availability characteristics would likely be compelling for SQL Server administrators who live in dread of Patch Tuesday.
"I wonder how many places are paying IBM, Oracle, Microsoft for a database when their requirements would be more than adequately fulfilled by using MariaDB or PostgreSQL, bolstered with paid support if necessary."
That works when you're dealing with your own home grown solution with your own devs and DBA's and the free DB's have feature parity with your current DB. (scale, performance, HA, etc)
There are plenty of commercial software and hardware manufacturers who support only Oracle/MSSQL with their product. When you're buying equipment that comes with their software, you're always buying a full stack. An expensive DB itself can be a minuscule expense on the whole when it runs a production line or a whole factory.
Also, strongarming companies like Agilent or Honeywell to support your choice of DB will not work. Depending on your requirements, there may be zero competition so either it's their way or the highway.
... that the world is moving away from legacy databases and towards Postgres."
So, extending your db to support SqlServer syntax is a sign that everyone is using Postgres.
I know sales droids don't have to make sense, but surely a basic grasp of logic would be helpful?
It is when you compare SQL Server on Windows vs. its Docker container counterpart. Note that I have not seen a single benchmark where you can tweak Postgres to run at least on par with SQL Server, if not faster. Since you have to get permission from MS to publish a SQL Server benchmark, this is somewhat expected.
And don't forget that the docker image eats memory like mad, so when you want to sping up a small dev/qa/test instance the SQL Server docker container will eat half of your machine just because it can't be bothered to change its configuration. This is unlike Windows where you can trim down SQL Server not to be a memory hog.
You can trim down SQL Server not to be a memory hog, but why would you want to? RAM is much faster than disk, and it is the buffer pool that is using all that RAM, a quick fetch copy of your database. In most situations this works much better.
SQL Server is probably already tweeked for Windows. As such, running on Linux may be "not as tweeked". Linux's file system and network stack are (from what I've seen) MUCH more efficient than Windows and as such there should be a CLEAR advantage to using Linux. But... since the SQL Server code is (as I understand it) CLOSED SOURCE, there is no easy way to find those bottlenecks where Linux may perform "not as well" compared to Windows [and then benchmark it or tweek it yourself and submit a patch].
Since I have not run a comparison, it would be hard to do anything OTHER than speculate based on the tests I have run, in the past. And years ago I determined that Linux and FreeBSD were about 30% faster for copying large files using SMB networking. In short, copy the same file with equivalent computers. and see how long it takes. But as I have not done this test since the mid-noughties, it's hard to say what the comparison is now. Yet, the PERCEIVED performance of Win-10-nic vs Windows 7 and XP does not show any serious improvement (and may in fact be "not as good" with Win-10-nic) I would venture to guess that my measurements in the mid noughties are still relevant.
So perhaps a tweeked SQL Server running on Linux could be 30% faster overall? That would be MY guess.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
