Announcing SQL Server on Linux
blogs.microsoft.comI for one am excited to hear about this move and was wondering if it would ever happen. This will help keep SQL Server alive and growing (I think) and who knows, maybe bits and pieces will even become open source some day (that's optimistic perhaps).
I am an equal opportunity consumer of database technology - something we all should be (e.g. use the right tool for the job when appropriate). I have used MANY different databases, open source and commercial, and there are better ones and worse ones across the spectrum. I think it is naive to criticize this move in any way - it is giving more choice so should be supported.
That said, SQL Server has a low barrier to entry, a very good implementation of the SQL language, an advanced optimizer, strong storage engine, management tools and a lot of nice BI features. Although you don't hear about it much, SQL Server also has Parallel Data Warehouse (PDW) which is their MPP database - ironically which used to be built using Ingres and Java of all things.
In my experience, SQL Server <-> PostgreSQL is the closest commercial to open source comparison (core database engine-wise) I can think of. This makes sense when you consider - both of them started as Ingres! Of course, Postgres and SQL Server have totally different user experiences (database management, tooling, etc.) and many different features.
Would you yourself actually choose SQL Server on Linux for a project?
I'm a big fan of SQL Server but the main thing that hurts it is the cost. Licensing our two servers today would cost a quarter of a million dollars. The OS cost is a rounding error. If I'm paying that much money for SQL Server I don't think I'd choose the Linux version for at least another 5 years from now. It needs to prove itself and there's almost no benefit to offset the risk.
I would never use MS SQL Server unless it is open source. Otherwise you get into vendor lock-in. Microsoft is cunning - they want to tie Linux-based businesses to their (expensive) products for good. But fortunately there is a viable open source alternative - PostgreSQL. http://www.pg-versus-ms.com
How are the clustering options coming along with PostgreSQL? The last time I looked into there weren't any multi-master solutions out of the box, but there were a bunch of separate implementations that mostly seemed to be half-baked.
https://wiki.postgresql.org/wiki/Replication,_Clustering,_an...
It's my understanding that the Postgres team has decided to change their historical stance of considering clustering solutions outside the scope of the core project, but I'm unclear exactly how far that has come.
The variety of different 3rd party implementations in various states of maturity make this a bit tedious to sort through.
That said, I always pick PG for my personal projects. I just have a hard time getting sign-off on it from my corporate overlords for anything at work.
http://www.postgresql.org/docs/9.4/static/different-replicat...
Async Multimaster is in the list of replication solutions.
I have not personally implemented it myself.
Edit, As I am reading this more closely it may be listing third party implementations and is not 'out of box'
Not that url again. It's RIDICULOUSLY biased and comes up every time SQL Server comes up on HN.
Out of curiosity, how does OSS prevent vendor lock-in? Are you talking more in terms of support?
It's very simple. With FLOSS you are not tied to one software distributor and you can freely modify and distribute the software by yourself. It is not about support, it is about freedom to run, copy, distribute, study, change and improve the software.
Anyone can support the OSS product to utmost level by studying the source code (and possibly fixing/modifying it).
> Are you talking more in terms of support?
Support is not tied to the product's license (which is common for proprietary software).
The sad truth is that "anyone can" is frequently still "nobody did, so you're on your own". This well applies to even the most popular pieces of FLOSS.
That's still significantly better than "noone but a single vendor can and you're at their mercy", but just being FLOSS doesn't mean it can't suffer from product lock-in, just that with the hurdle being complexity and not copyright.
There's always friction, yes, but rarely a lock or you'd simply go into the code and remove it.
Natural complexity, when the domain is simply complex to model, can't be gotten rid of regardless of the product.
Ah, the lock is not something that check the license and tells "oh no you're not allowed". It's a combination of not having something, and complexity to add it. Sometimes, that's because you need something tricky. Sometimes, that's because the project lacks any documentation, is written in a pretty low-level (verbose) language that obscures the high-level picture, and it's hard to figure out how it works. Sometimes, that's because FLOSS != KISS, and there is a lot of FLOSS software that has its own unique proprietary protocols and data formats, and does things in a manner that's completely incompatible and non-interoperable with any other system. I have no clue about MySQL or PostgreSQL internals (actually, I heard a word they're good in this regard), but is the case for various FLOSS projects - I've dug into some and cursed their developers.
If you overcame that and made a patch, but it's not accepted by the upstream - there are maintenance costs. How long would you be able to maintain your own fork of a large software project, keeping up with the upstream? I've tried with a few small ones (say, at a small ISP company, I just needed some custom pppd patches for in-house billing logic), and found it to be not a pleasant experience. I believe it's not just because I'm a lazy ass - I saw tons of forks on GitHub that were slowly rotting away, maintained for some time but eventually forsaken by their authors and far behind their upstreams.
That's what a lock is - something intentional. Everything else is natural complexity. Nobody made their code complex because they felt like it.
> If you overcame that and made a patch, but it's not accepted by the upstream
As for how well the FLOSS projects are managed, how's your luck at debugging let alone getting a patch accepted in MS-SQL, for instance?
> I saw tons of forks on GitHub that were slowly rotting away
I saw people with food, who weren't eating it because they were full, and I decided that food was stupid. Right?
> How long would you be able to maintain your own fork of a large software project, keeping up with the upstream?
Far longer than a binary patch... You know, to block a certain cipher suite or something in a closed-source product.
> how's your luck at debugging let alone getting a patch accepted in MS-SQL, for instance?
Duh, none or nearly none, of course.
I'm not saying that proprietary binary blobs are better. There are exceptions, but generally they're significantly worse in this regard.
I'm only saying that just because software is FLOSS doesn't mean one can successfully hack on it and adapt it to their needs, or easily migrate to other FLOSS solutions. Sometimes, they'll be stuck for a while - I think that's also can be considered as a lock-in.
> Nobody made their code complex because they felt like it.
Maybe. But there's a term "over-engineering" too. It's not that someone decides to make things unnecessarily complex, but sometimes they really do.
> Would you yourself actually choose SQL Server on Linux for a project?
It will significantly reduce the licensing implications of using SQL Server for a small project. I know people who use MSSQL in their day job but postgres/other for personal projects and one of the reasons is needing to license Windows if a personal project becomes public and needs hosting. This way a small project can use SQL Server Express on Linux just as cost free as progres (or mysql if you must) on Linux.
The choice of OS will no longer dictates the choice of DB, that decision can be entirely made on the needs of the project and its target users.
Small projects using Express edition may grow into larger ones needed standard/enterprise features, and people exposed to SQL Server through projects using it on Linux are less likely to dismiss ti later because the know postgres/other only. I'm not sure how much we'll see brand new larger projects use SQL Server on Linux any time soon though, but I imagine "get them in at the ground floor and create familiarity as early as possible" is the intention here much like cheap educational licensing for Windows, Office, & full VS and the availability of VS Express.
BizSpark is the way Microsoft encourages side projects/startups to use MS SQL, but yes, this removes a hurdle, and separating the choice of OS from the choice of DB is good.
That said, I use MS SQL both at work and on my personal projects thanks to BizSpark.
There's also Azure, which, to be fair, is still more expensive than an equivalent AWS stack with Postgre or something.
Many of the stability issues I've seen with SQL server have been the fault of the OS or Windows drivers
Conversations I had with some senior SQL server team members in the last two years suggested they were ready for no reboot patching but were limited by the OS and felt it was holding them back. If it wasn't for Windows, SQL server uptime would be much better (was the implication)
I'm looking forward to trialing it.
For smaller businesses they can join Bizspark and download SQL Server free from msdn and keep it even after the 3 year program ends.
In theory. In practice our hosting provider couldn't do this for us because of their own licencing (or it was too difficult for them to work out).
And if you are a start-up, you will upgrade your DB, in which case you might only get a few years free anyway.
Host companies have to license you a copy through the Microsoft SPLA program.
I think this will be a great option for existing SQL Server users wanting to move to Linux. Looks like MSFT is slowly giving up on Windows Server to some extent. They might be seeing more money in the Cloud business compared to the Server OS business.
Or rather hope or predict to see more money. There is a lot of wishful thinking involved in the current shift to the cloud, both from providers and their customers.
> Would you yourself actually choose SQL Server on Linux for a project?
Well, I might KEEP my SQL Server, but switch from Windows to Linux as the host OS - to save $$ on licensing and hardware.
Wasn't the core of SQL Server actually Sybase?
Kind of. Sybase and Microsoft actually partnered for a while but parted ways in the mid-90's. https://en.wikipedia.org/wiki/Adaptive_Server_Enterprise
(I actually remember using Sybase SQL server for a while until the tool that would eventually be called Enterprise Manager was released.)
> I think it is naive to criticize this move in any way - it is giving more choice so should be supported.
It's naive to support it just because of the assumption that more choice must be good.
On the contrary the past few years on Windows have been full of data corruption bugs in SQL 2012 and 2014; and while 2016 looks amazing with new features Microsoft has continued to push ahead instead of just - you know - fixing the fucking bugs we all keep reporting and upvoting on Connect and getting ignored.
More choice is IMHO not a good thing. It's a bad thing. In the same way people who "multi task" are more often than not churning out shit work and running on luck - I'd prefer Microsoft focus on what they know best.
You think that allowing corporations to move their SQL server investment off of Windows and onto Linux as a precursor to moving off of SQL server, rather than forcing them to change DBMS and OS at the same time is bad? That's what choice means.
Those who are moving off of MS SQL are "lost customers" and I don't think MS would be spending extra resources on facilitating their transition. More likely they had customers willing to switch to/stay on MS SQL but needing Linux for some unrelated reasons.
While I do think this is a good thing, I've run very good MySQL servers (well, in so far as MySQL is ever very good) on Windows, so it was already possible to do that kind of migration.
Coming from mostly a Linux/MySQL background, I've had reason to use MSSQL for the last few years. It's really solid, and seems to optimize queries well, which is good, because there's a few things that I still find really annoying, such as no GROUP_CONCAT. There is a more general method to do the same thing, but wow is that method cumbersome in comparison (although undoubtedly more powerful).
> optimize queries well
There are a few obvious cases which don't work (e.g. scalar UDFs aren't inlined - always use table UDFs), but the performance battle Oracle and Microsoft had circa 2000 really shows. The vast majority of the time you can code your intent and the query optimizer will simply do the right thing.
The main reason I would choose SQL over any of the competition is DataDude/VSSQL. We started using it where I work (~5100 schema objects) and it's revolutionary. T-SQL becomes a first-class language in Visual Studio:
- Full editor integration: intellisense and errors as you type.
- Build system: build (including static analysis) and deploy from Visual Studio. MSBuild-based integration for CI.
- Schema delta: you write/update your schema as though you are writing it for the first time and, as part of the build, the ALTER script will be generated for you. You rarely have to write migration scripts yourself (I've only had to when migrating data across columns/tables).
I have been thinking about solving this for PostgreSQL because I'm now completely unable to work without it - I just wish I had the time. Any other form of SQL development now feels like VBScript development in Notepad.
Links to more information about this? I've found some information about VSDBPro but it all is dated 2008. I like the sounds of this, but it seems dated...
Update: Seems like this has become SQL Server Data Tools (but not the BI tools of the same name?). I'll have to look into this more.
As far as I remember it has only ever been optional in VS2010. It was introduced by default in 2013 (.dbproj) and then reworked in 2015 (.sqlproj). All you need to get this going is: Visual Studio > File > New > Project > Other Languages > SQL Server.
You can also get it to reverse-engineer an existing database into a project[2].
Getting it to work for CI isn't turn-key. When you build a SQL/DB project it results in both a CREATE/ALTER script (depending on whether you do a diff build or a CREATE build) as well as a schema file (.dbschema). You need to track previous versions of the dbschema yourself (we use branching to track this file across releases), so that it can it has the base for diffing during the build.
It's a good idea to add a database reference to [sys] and [master] in all your projects (which is not done by default).
Knowing the right keywords I Googled a bit for you:
[1]: https://visualstudiomagazine.com/articles/2015/01/01/visual-...
[2]: https://www.youtube.com/watch?v=kWKllVyozOg (talks about SQLAzure, but these tools do work on-premise)
[3]: http://www.codeproject.com/Tips/998465/Creating-a-SQL-Server...
[4]: https://blogs.msdn.microsoft.com/ssdt/2014/07/24/sql-server-... (if you use TFS CI, otherwise you can invoke MSBUILD directly from whatever CI you use)
This is also my big complaint when it comes to MS SQL -- there has been precious little development on their SQL language. It's almost like they're in a complete feature-freeze when it comes to the SQL language.
MS SQL is missing some very basic SQL functionality.
SQL Server was based on Sybase SQL Server. https://en.wikipedia.org/wiki/Microsoft_SQL_Server
Microsoft rewrote the code so there was no more Sybase code, but it still followed Transact SQL standards. T-SQL is not as complete as PL/SQL and others. It is just that Microsoft is that 800 pound gorilla so people use their products.
My last job I did migration from Excel and MS-Access to SQL Server using VB 6.0 code and ADO recordsets to copy and sync up data. They key was to use a column named date modified that had a time stamp when it was last modified to figure out which record was the newest and back up the old record to a history table in case it needed to be reverted later on.
I thought Oracle or even db2 would be the Gorillas for serious corporate/goverment databases, and MySql would be the Gorilla for cheap + web stuff.
I suppose Microsoft is pretty popular in beetween those 2 markets.
Oracle IS the gorilla, but with their recent pricing/licensing moves, more large orgs are exploring moving to SQL Server, especially ones that are already a Microsoft shop. My company is doing just that.
Why not explore PostgreSQL? You would be free of licensing/pricing moves.
Not GP, but I've found SQL Server significantly easier to both install and manage. Performance-wise I've yet to encounter a significant difference.
What in particular do you miss from other SQL languages?
Date handling, simple things like postgres date_trunc('month', now()) and especially looping over records in stored procedures without using cursors (that are prone to crashes).
I work with both on a daily basis and there is a mile of difference. Yes I can accomplish whatever I want in sql server but there are so many small things that could improve.
Some of other pet peevees are: You can't use a lot of left joins, it slows down the query dramatically. If there is only one to one relation, use subselects instead.
Thou shall not do queries like this: select foo into baz from bar where fooid not in (select fooid from bar) They are the death of the engine.
And many "unwritten rules" like that.
Postgres just accepts the queries and run them..
SELECT DATEPART(month,GETUTCDATE()) ? Either you are using a very old version or not using SQL Server at all cause I pretty much do everything you are complaining about on a daily basis and on a very large set of data.
Your query only extracts the month integer from a date, it does not floor it to the month. The equivalent for sql server is this ugly thing: select dateadd(month,datediff(month,0,getdate()),0)
We are on SQL server 2014. I have had a query go from 2-3 hours down to 7 minutes by replacing left joins with subselects within the query for instance (and yes all the indices are in place as recommended by sql server query planer)
The one with a insert based on a query on the same table I have never managed to run at all and I have to use a temporary table as an intermediary instead.
The last one might be heped by trace flag 4199. You can apply it to individual queries with option (querytraceon 4199):
https://blogs.msdn.microsoft.com/psssql/2010/09/01/slow-quer...
I have seen Sql server query planer do stupid shit too. Almost always Statistics where to blame. Are you sure those where up to date? For some reason the "auto update statistics" functionality doesn't seem to work reliably, you have to update them in a maintenance job to fix this.
UPSERT (or similar logic, not merge).
Oh, then that's your problem. MERGE is standard, and has clear semantics. UPSERT is nonstandard, and semantics vary among implementations.
Microsoft doesn't need to make SQL Server look like MySQL. Quite the other way around.
There's not really a standard anymore for UPSERT to be added to. SQL has fragmented and since the last few iterations of the standard allowed for "additional non standard features", adding an UPSERT is perfectly compliant with the SQL standards.
UPSERT should be a standard, why isn't it?
And it's very useful in a ton of situations which is why so many other SQL dialects have added it. It's not like SQL Server is completely standards compliant so I'd rather have the functionality then have to use MERGE because it's "standard".
Agreed on GROUP_CONCAT. MSSQL has been missing that for a long time and it is a very reasonable and handy function to have.
It sounds like you are talking about the XML conversion method for concatenating groups. There is one other way around it using custom .NET CLR functions, but it is definitely cumbersome as well.
Yes, I'm referring to the XML conversion method. I'm aware you can register your own .NET CLR functions, but truth be told, it's a database for our POS application (which we purchased from a vendor), so I try to mess with the database as little as possible beyond reading the data through our own internal application so we can do useful things with it. I try to stay away from messing with the schema or even providing extra routines (I can't be sure anything would survive upgrades, which are regular and I don't want to deal with that).
Can you share any links which cover the more general and powerful approach in detail?
>as Ingres
I've read that SQL Server code was originally based on Sybase code they licensed. Not sure.
MS SQL Server was based on Sybase 4.2 as I recall, which is the Sybase release that predated introduction of SMP support. (Internally known as the "boat anchor" though I doubt that name appeared on the contract to sell the code.) Microsoft basically rewrote it, so I would guess there is little original Sybase code left. You can still see the the heritage clearly in features like T-SQL dialect and the Tabular Data Stream wire protocol, both of which were developed at Sybase.
Sybase is not in anyway related to Ingres that I know of other than the fact that Bob Epstein and Mike Stonebraker worked on the Ingres project at Cal. Sybase in fact was considerably different from Ingres in many ways such as use of SQL instead of QUEL, network access to the SQL Server, and specialized features like stored procedures. The Sybase founders did not come directly from Cal or even Ingres but rather from Britton Lee.
Yes, true, and Sybase is a descendant of Ingres.
Intellectually, somewhat, perhaps. Sybase was a distinct implementation. When it came on the market, Ingres IIRC was still based on QUEL. Sybase had its new T-SQL language and a novel design that made it feasible to use for OLTP. At that time, Ingres and Oracle were usually devoted to decision support, and OLTP was backed by things like VSAM.
Noted, thanks. I did think that might be the case, but I was thinking of direct parent. Anyway, good to know. Stonebraker et al?
You are actually not far off. Sybase was founded by Bob Epstein, who was Stonebraker's student at Berkeley and helped build the original INGRES system.
And Microsoft SQL Server is a descendant on Sybase since SQL Server 6, after Microsoft purchased the source code.
> SQL Server <-> PostgreSQL is the closest commercial to open source comparison (core database engine-wise) I can think of.
Can you store / query JSON-like data in SQL server? I'd like to be able to store a structured object and query a keypath.
MS SQL does support XML types / allow you to use XPath in your queries. To my knowledge it doesn't do JSON; but its easy to convert between the two.
http://blog.sqlauthority.com/2012/04/27/sql-server-introduct...
SQL 2016 does JSON https://blogs.msdn.microsoft.com/jocapc/2015/05/16/json-supp...
I wish people would stop saying this. The JSON support in SQL Server 2016 is far from being comparable to the JSON support in pgsql.
Well actually it "supports" JSON as NVARCHAR. There is no JSON type and no JSONB type that supports indexing like in Postgres.
Nice to know, they query syntax is, unfortunately only slightly nicer than the XML options... at least at first glance.
As the two other comments note, SQL Server 2016 will support JSON, however the extent of the support is significantly less compared to Postgresql.
This is unfortunate as I'd love to have better document-db style functionality in SQL Server.
2016 supports JSON.
It has terrible support.
Dumping a load of JSON into an RDBMS makes CJ Date cry
And it probably makes Fabian Pascal go postal :)
I too am excited, as I was faced with the challenge of building a rails app with a SQL server database backend. Sure there is a solid adapter, but it wasn't perfect, and we couldn't effectively run tests on it.
It won't be generally available until mid-2017.
I've built a Rails app atop a large legacy SQL Server, and I really haven't run into anything that wouldn't run. (aside from `rails db`)
Is this the same DB that backs the StackOverFlow/Exchange network of sites?
Yes
Looks like basically everything will be on Linux at SE now. ;-)
Stack Overflow dev here.
We don't really care that much about the OS -- never did, never will. A windows license is very cheap, and we only need maybe 20 windows licenses to run the whole network.
The much bigger cost are SQL Server licenses, for which we care very much about!
All in all we'll keep on using SQL, but on the most performant platform -- my bet is that it's going to be Windows for a while though.
Regarding .Net Core: the platform is not ready yet (e.g. lack of support for Security IIRC), but we'll adopt it when it is -- again on the fastest platform.
Both in the case of SQL Server and .Net core, we are working publicly on GitHub with Microsoft by testing and providing advice where needed to make sure the next version of our ecosystem is the best possible.
Their web/service tier are still windows, doesn't seem that likely that they'd rewrite them in .netcore fast enough to be off windows completely in the near future.
Any idea how MSSQL was deployed on RDS in AWS prior to this? Was AWS spinning up some custom Windows instances behind RDS?
Or was the RDS implementation part of how MS figured out how to release this??
SQL Server RDS is built on Windows. Albeit a scripted to the 9's adaptation to make it act more Linux like (e.g., RDS can't connect to your AD, so they had to make some sacrifices).
The big difference with RDS is that you don't get the full gambit of clustering capabilities that SQL server supports. This is mainly due to the fact they don't have a shared storage model that SQL cluster failover requires.
EBS is certainly capable of implementing the shared storage that the database requires, and the quorum driver for wolfpack ought to implementable without a physical scsi device backing it.
At least until recently the MS SQL Server clustering was based on mirroring, which is capable but deprecated in future SQL Server releases in favor of AlwaysOn clustering.
The syntax of MSSQL is very behind the competition and still based on Sybase. Even basic string functions aren't available or have weird arguments.
If you aren't locked into their eco-system stay clear away from it. Otherwise you will regret it, as the licensing costs are very expensive and per CPU core (think Oracle). Better switch to MySQL or Postgres or Lucene, etc.
There is more to a SQL server than the language.
For example, OLAP, distributed transactions, cluster scalability and so on.
You get the same features from other databases.
If we are speaking about Oracle, Informix, DB2, Sybase, yes I do agree.
yes, but there are others too. And MySQL and Postgres support some of those functionality as well.
I work on a software product that supports MySQL, PgSQL and SqlServer (if they run it on Windows, since we only support the official Windows PHP drivers).
SqlServer has always been the best performing and least troublesome database in terms of weird edge cases, backup, restoration, and (especially!) performing expensive SELECTS on databases that have grown into the 100's of Gigabytes in size.
Based on my experience, for all the (often deserved) hate on M$, SqlServer is really a shining star.
That being said, I am a little scared to support SqlServer on Linux, as I imagine it will have to be different in quite some potentially fundamental ways to work on Linux - I'd love to hear if anyone has opinions on that aspect.
Keep in mind that SQL Server basically runs on top of it's own conception of an operation system even when installed on Windows. It's called SQLOS and the work done on that was probably what largely enabled this to happen because there was already an existing layer of abstraction in place for development to use.
That said, I think that this will probably come with a large amount of caveats, for instance, I wouldn't be surprised if when it launches it's just the core SQL engine and not the extra pieces (SSIS,SSAS,SSRS,MDS, et cetera).
From the SQLOS announcement: "Keep in mind SQLOS doesn’t provide OS abstraction layer to SQL Server. It doesn’t warp any of Windows APIs for portability purposes. Contrary it continues further binding of SQL Server to Windows by exploiting scalability and performance features of the Operating System."
http://blogs.msdn.com/b/slavao/archive/2005/02/05/367816.asp...
Makes sens since SQL Server granpa is "Sybase for OS/2". There are probably very few lines of code left from those days (-94:ish), but the way of thinking is probably still there and what enabled this.
SQLOS is a relatively new component, it was introduced for SQL Server 2005.
http://blogs.msdn.com/b/slavao/archive/2005/02/05/367816.asp...
> Keep in mind that SQL Server basically runs on top of it's own conception of an operation system even when installed on Windows.
What is the reason for this?
An operating system is usually optimized to perform well for a large variety of workloads. Databases have a very specific workload and there are some possible (performance) optimizations if you, for example, bypass the operating system file caching and prefetching facilities and roll your own. Or if you control the scheduling of your operations. Take this with a grain of salt, it has been some time since I read about SQL Server internals, but this is what I remember.
>bypass the operating system file caching
Using raw partitions instead of file system files for database storage was common practice with Oracle and other DBs at one time. Not checked lately.
db2 used to support/recommend raw block devices (this was ~8 years ago). I believe nowadays they are recommending using regular filesystems again.
Good to know.
I understand, but that implies that the underlying OS is suboptimal for the task, doesn't it? I mean, Postgres doesn't do that in Linux, right?
They don't, but that's not because they lack frustrations with Linux.
If you think about what a DBMS does, you'll find the list looks a lot like an OS: I/O, memory management, task scheduling, resource arbitration. And the DBMS makes guarantees the OS does not, not least of which is transactions. To the extent the OS could supply the functionality needed by the DBMS, it must do so in a general way. The DBMS can implement specialized logic that increases both efficiency and certainty.
A textbook example is a file buffer. The OS provides write(2) or similar. It affords the abstraction of a linear sequence of bytes. The caller can write 1 byte or many, and the OS will take care of allocating/locating the block(s) and updating them. And write(2) doesn't even write! If you want to change the bits on the platter, you need fsync (and some faith in the hardware).
A DBMS by contrast is typically organized around pages, the size of which is a function of the disk blocks. Some of those pages maintain critical state information and are sync'ed to the disk frequently. The DBMS must also guard against data loss because of (say) power failure. It may choose to keep two copies of such data -- Jim Gray's so-called "ping-pong" algorithm -- so that even if the last one is corrupted due to insufficient voltage, the prior one will be OK. The DBMS's view of the disk is one of blocks, not bytes, that are strategically situated to minimize time lost waiting for it to spin or seek. The metaphor for writing data is less one of a stream and more like whack-a-mole: pop, pop, pop, done!
The astute reader will note Posix offers no services in support of splatting strategically situated blocks on the disk. I never read the code, but that would explain why Sybase in 1986 and 2016 lets the user define the database outside the filesystem.
Regarding Microsoft's Linux offering, we're coming full circle. The code Microsoft licensed from Sybase included an OS isolation layer in which Sybase implemented all those OS-like services. To VMS, for example, Sybase was just 1 process, and Sybase itself managed the multiple connections and tasks. Microsoft incrementally, version by version, stripped that away and insinuated the DBMS into the OS. Doubtless there is kernel support in Windows specifically for SQL Server.
Later, mirabile dictu, we're told SQL Server has "its own OS". I suspect that layer was created as much for organizational reasons as technical ones. It lets the two groups define an API for use by the DBMS. The DBMS group gains some control, and the OS group isn't at their beck and call. But it turns out to be useful beyond that. I have to imagine one reason "SQL Server on Linux" is still a year away is that adapting that OS-interface layer to Linux is a nontrivial effort.
> I suspect that layer was created as much for organizational reasons as technical ones. It lets the two groups define an API
Conway's Law strikes again.
Very interesting! I had the (mistaken, then, I guess) impression that sqlserver was super win32 specific, using "fibers" for threads and every peculiarity in the book. But this is just a vague impression from old articles I don't really remember
SQLServer is super Win32 specific, even to the extent of using undocumented Windows APIs (I think the canonical example is NtReadFileScatter and NtWriteFileScatter, which are more flexible than the documented ReadFileScatter and WriteFileScatter wrappers; I wouldn't be surprised if it uses many more undocumented calls).
SQLOS isn't an abstraction layer over the operating system necessarily. It's more of an abstraction over the _machine_ that allows scaling between 8GB and 512+GB of RAM, 4 to 64+ cores, etc.
That said, since SQLOS does handle all memory management and file I/O for SQLServer, it probably did make porting slightly easier.
Actually, "fibers" are a custom abstraction that can be used instead of threads, but SQL Server uses the threading model by default.
So you're right, I do think it will be an engineering challenge, but as parent mentioned, the fact that SQL Server kind of treats the OS itself as abstract means I think they might have a path forward. Otherwise, I don't think they would have announced this.
Another way of thinking about this is, maybe the low-level refactoring necessary to make this run on Linux will actually be good for the SQL Server engine, although it will most likely go through a period of serious instability while they figure out how!
> I work on a software product that supports MySQL, PgSQL and SqlServer
"SQL Server on Linux" really means "More developers will be able to offer compatibility with SQL Server" - those who use Mac OS X and Linux as a primary environment.
My software supports PgSQL, MySQL, H2 and Oracle because they can run on my Macbook, or at least in a Linux VM. I explicitly exclude MS SQL because I'm not able to install MS SQL Server to test (at least not with a legal license). It's the same for continuous testing: It's easy to launch a Linux VM on a VPS, it's much less easy to launch and execute automated tests on a Windows machine.
FYI: There are express and the older desktop versions available for free.
OT but Servers for Hackers was a great resource for me when learning Ansible - kudos.
From http://www.zdnet.com/article/microsoft-is-porting-sql-server... -
"The spokesperson also acknowledged that Microsoft won't be bringing all of the same capabilities in SQL Server 2016 to Linux; it will be just the "core relational database capabilities."
As somewhat expected this will be a limited release catering mostly to cloud customers (Azure in particular) - who knows down the road they will port all features to Linux including the UI management tools but I would be surprised if they don't keep the niche features Windows-only.
Welcome announcement anyway - having a supported mainstream DB other than Oracle on Linux is a good thing.
> I would be surprised if they don't keep the niche features Windows-only.
For some definition of niche, which in this case may very well include "enterprise class features" such as replication...
This is a way for MS to increase exposure and draw people into their ecosystem (at least for a part of their infrastructure) in an increasingly OS agnostic world. I don't think it makes sense for them to cannibalize their current revenue sources to do so, and a part of that is requiring expensive Windows Server licenses for high-end MSSQL features.
Yeah, replication, encryption, memory optimized tables, search etc. come to mind.
To my mind MySQL and PostgreSQL are both more mainstream than either Oracle or MSSQL, and it's possible to buy a support contract for either?
Mainstream yes and you can buy support for them but they are not supported by majority of the Enterprise 3rd party/COTS software. Most enterprise products you can license only work with Oracle on Linux.
i dont think this is correct from the article in this post
"We are bringing the core relational database capabilities to preview today, and are targeting availability in mid-2017."
so you will have the core capabilities in 2016, but by mis 2017 i am expecting the full thing
I would never use SQL server willingly but I really like the direction Microsoft is taking lately. They are a software company and restricting their software to PCs running Windows only doesn't make sense.
I hope it continues. I've been caught in a bind twice in my career when Microsoft offered their product on a non-Windows platform and once it started to develop critical mass, the platform was dropped in favor of Windows only. (FoxPro being one example.)
I obviously have no idea what went into the decision, but it felt like it was an attempt to get people committed to the product then strong arm them to Windows.
Even today, for mainstream products like Excel, they still hold back key features from a major platform like OS X. (E.g., https://support.office.com/en-GB/article/Compare-Excel-2016-...)
This is partly why I do not buy that they've given up on Embrace Extend Extinguish.
They have another decade worth of good behaviour owed before I'm willing to consider giving them the benefit of the doubt. But that's me.
> they still hold back key features from a major platform like OS X.
I don't think "hold back" is the right term. It's my understanding they share some code between the platforms but for a lot of the GUI they do not so it's expected many of the OS X features are simply not done / lower priority than other features.
That's true. For me, the Flash Fill feature keeps me going back to a Windows VM just to use Excel.
ms sql is better than mysql. downvote me all you want, but you can't possibly disagree if you've tried both like I have. transaction isolation anyone?
don't have much experience with postgres, but my money is still on mssql
> ms sql is better than mysql.
That's one hell of a benchmark, up there with "eating paste is better than being on fire" and "missing a hand is better than missing a head".
> don't have much experience with postgres, but my money is still on mssql
Obviously, since postgres is FOSS.
If you ever become a comedian (unless you're already one) I will gladly shovel money at you to tell me jokes ... I was thinking the same thing, but could not express it as viscerally.
PostgreSQL is pretty amazing. MySQL isn't even in the same league as PostgreSQL. I'm sure MSSQL is nice, but my money is on PostgreSQL being even nicer.
https://www.reddit.com/r/programming/comments/2mhpwp/postgre...
MySQL is hardly a relational database, it's not quite the benchmark you're looking for.
I'm sure MSSQL is nice, but my money is on PostgreSQL being even nicer.
Having used both, I'd take that bet. MSSQL is in my opinion the best DB out there in terms of ease of use, documentation, integration, and tools. PostgreSQL is a distant second, and SQLite is probably a distant 3rd (though it's really not in the same category).
> documentation
The pg documentation is quite through and informative.
> integration
Meaning? "Integration" in and of itself is meaningless because that depends on what we're integrating with. Rust integration? pg is much better. Some obscure windows-only business tool that most people have never heard of? well, it integrates with what they want it to (probably mssql). Some obscure BSD-only business tool that most people have never heard of? well, it integrates with what they want it to (probably pg or mysql).
> tools
Again, meaningless unless you discuss what the actual differences are. Being able to be used on BSD makes pg infinitely superior in terms of tooling for my cost function.
Tell me of these BSD-only business tools
In my experience, people who like MSSQL are the kinds of people who prefer to use a GUI to access their database (or Entity Framework). Basically, the user experience is like this:
PostgreSQL: Just nice. Every once in a while, you learn about a feature that makes things easier.
MSSQL: Plain vanilla, slightly outdated. Works. Nothing fancy. Expensive.
MYSQL: Every once in a while you learn about a feature that makes things harder.
It sounds like you haven't used MSSQL in quite a while. The 2012-2016 editions have progressed significantly. 2000-2008 were pretty vanilla but then most databases of that era were.
Pricing can be expensive if you need the standard, BI, or Enterprise editions but otherwise it's not. It's no where near the cost of Oracle though.
You're wrong.>It sounds like you haven't used MSSQL in quite a while.
Instead of saying "it progressed significantly," why don't you list these features that are so great? Come on, sell this product that you like so much! Help us understand why you like it!>The 2012-2016 editions have progressed significantlysome of them, off the top of my head.. columnstore index, in memory tables, R integration, Always ON, Stretch DB, Dynamic data masking, encryption at rest and transit (always encrypted), row level security, temporal tables, JSON support, query store and stats, live query stats,polybase, backup to cloud, TDE enhancements, replication enhancements, TSQL enhancements, FK relationship limit, managed backup, multiple tempdb files, trace flag improvements, db scoped configs, query optimizer improvements, HA-DR improvements, replication enhancements, Master data services, data quality services, SSIS catalogue, SSIS project model and execution, mobile reports in SSRS, datazen integration, HTML view in SSRS, tabular mode in SSAS, improvements to UDM model in SSAS, DAX language and improvements.. And I got tired of typing...
MS SQL has the best GUI for administration of any database I've used, if that sort of thing is important to you. Hands down better than anything I've seen for a free database or even Oracle. In that sense you do get what you pay for. I'm not sure how they'd bring that to Linux other than maybe with Wine or other emulation layer.
The past couple editions of Microsoft's management tools have just been front ends for powershell commands on the back end.
> SQLite is probably a distant 3rd (though it's really not in the same category).
Definitely not in the same category: the goals for SQLite are very different to those of MSSQL and Postgres.
It is impressive how well SQLite performs and scales so you sometimes see it do the job of a "larger" engine because a project accidentally grew and hasn't been re-factored in that respect yet, but if you are starting a new project I can't think of any cases where you would ask yourself if you should use it instead of MSSQL/Postgres. For an integrated storage engine for your app with SQL semantics, ACID, and so forth: SQLite wins hands down. For a fuller database and anything that needs any significant concurrency SQLite is not what you want and isn't trying to be that.
You're absolutely right, though given the choice between developing a large scale app with SQLite or MySQL I'm afraid I'd go with SQLite. At least I'd know what hell I've wandered into.
We are in danger of encouraging a small war here, but I would partly agree with you in that I would not by choice use mySQL for anything. IMO there is nothing for which one of SQLite or Postgres (or SQL Server or other decent RDBMS) are not more suitable for. mySQL and its descendants/variants are popular today mainly because of a mix of two things: many people not knowing better and its popularity having significant momentum.
I still wouldn't use SQLite for a large scale app (assuming that means one that needs concurrent data access for multiple users) though: it is not the right tool for that sort of job.
Does MS-SQL have anything like PostGres' Bidirectional replication?
Also, Postgres is missing multiple result sets, which Sql Server seems to have, right?
I'm not as familiar with later versions of MS-SQL, but it's replication story is well in the box... Postgres is a bolted on, hard to setup/maintain hodge podge... I really hope the out of the box, via a gui admin and all story for replication on postgres gets to where MS-SQL was in the box in 2005.
NOTE: this is not a bash or nag on postgres, I really like it's JSON integration, and plv8 is awesome. That said, even simple replication stories in pgsql have me pulling my hair out, mainly because I don't WANT to know every intricate detail about my dbms, I just want to build applications on top of it, and ms-sql is pretty nice in that regard.
Admittedly I've never used the replication in Postgres but that surprises me. I don't think I had the opportunity to use replication in MSSQL 2005 but it was pretty awful 2003 and pretty terrific in 2008 so I guess it was fixed somewhere in between.
Does MS-SQL have anything like PostGres' Bidirectional replication?
Yes.
One thing to be said about Microsoft and their products is that they probably support what you want to do. It may cost you an arm and a leg, but it's probably supported (as with most high-end enterprise products, I find). It's easy to see how this came about, too. "We have a multi-million dollar sale on our hand, but they really want feature X. Guess we can subsidize the development with that sale."
I feel like cost has only really become an issue recently with their drive to get everyone in the cloud or on Azure and even then it's only an issue for small businesses. They offer ridiculous discounts to nonprofits and in education settings it's basically free.
Sadly, even the basic synchronous mirroring with automatic failover that MSSQL offers is ahead of anything pgsql can offer at the current time.
SS is more advanced than PG out of the box. Built in scalability and HA; far more reliable point in time backup/restore; PG even only had a plan cache added recently (the past year or so?)
Then you have full text search, built in columnstore, in memory tables, native procedures.
That's not counting all the non engine stuff. There is no adequate free software equivalent to reporting services or analysis services.
Sorry PG isn't even close. PG is no doubt extremely important and the best of the free software pack. And you will pay your life to MS for adequate licensing. But there really is no comparison.
MySQL on the other hand is a flat out joke.
> Then you have full text search, built in columnstore, in memory tables, native procedures.
Err, Postgres has full text search, columnstores and native procedures. Memory tables is slightly different, but doable.
It's an open source project with extensions, you can't just classify it by the core.
Lets not forget proper JSONB support. Oh god it's the most amazing thing to ever happen to a relational database.
> far more reliable point in time backup/restore;
Hmmm. I use ZFS snapshots for backup of my PostgreSQL instances. It's faster, as reliable as it can be, and I can run a full backup every fifth minute and keep the snapshot history on a database that weights 2TB.
> PG even only had a plan cache added recently (the past year or so?)
What? You have no idea what you're talking about.
> you have full text search, built in columnstore, in memory tables, native procedures.
Postgres has all of these (column stores only available as extensions).
I don't think you're very familiar with Postgres.
This precisely. MySQL has made headway in recent years but is still miles behind PostgreSQL. No commercial database is in the same league when it comes down to it either. Oracle has some nice stuff that PG doesn't have yet but PG is still the nicer database overall.
What metric are you using to compare databases? It sounds like you're saying MySQL, while crap, is better than commercial databases.
I read it as saying Postgres is better than commercial databases.
Other gentleman is correct. The tier list is pretty simple.
MySQL < MSSQL < Oracle < PostgreSQL.
Basically PostgreSQL is king of relational databases right now.
MSSQL < Oracle?
No way. Maybe Postgre is nicer than MSSQL for you. I don't know. But Oracle? Oracle is worse than MSSQL in just about every way that matters.
Why?
Free + Fast + no weird syntax (like Oracle) + Most features (although I think Oracle replication might still be better)
Oracle replication usually requires Golden Gate to the best of my knowledge. Someone was telling me the other day they hacked their own system together with shell scripts (ship and restore log files using scp etc), but that's probably not something you'd want to build your business on.
So yes, Oracle replication is probably better if you use Golden Gate. But Golden Gate is pretty expensive (17k per CPU?).
I'm still unclear under what criteria Oracle comes out on top of MSSQL. Aside from the extreme high end, I can't think of a circumstance where I'd prefer using Oracle to MSSQL.
For MySQL vs PostgreSQL, I link people to this one: http://grimoire.ca/mysql/choose-something-else
Microsoft's HA and replication user experience is light years ahead of PostgreSQL's from an operations perspective last time I checked.
What a ridiculous statement to make!
That first link has been discussed many times on HN and the consensus always is that the author is extremely ignorant.
He acknowledges his crassness at the bottom. Unfortunately, sometimes ignorant people have a point. Native regular expression support is a big deal, if it balances towards a better platform is another question.
I will agree with you on that one, but one is free and the other isn't. Postgres, however, is free and blows MySQL out of the water. Each has their pros and cons though.
SQL Express is free, but limited :)
> ms sql is better than mysql.
Well, gosh. I'm convinced.
(Full disclosure: I abhor MySQL. But if you're paying attention, you'll notice that my position is a statement of opinion, while yours is a statement of "fact". The reality is, every RDBMS has strengths and weaknesses, and should be evaluated for their applicability to a given project on a case-by-case basis — at which point, I'm sure, you'll conclude that PostgreSQL is the best choice, anyway.) ;)
The thing is I wasn't trying to convince anyone though :) I doubt anyone here will be willing to shell out the money for a license. Although, Azure might make it affordable but I hated the limitations they put on the mssql instances (can't remember them rn).
My biggest problem with myssql is that it is very immature. Biggest problems I have with it are (right now, b/c that's what I'm facing atm): transaction isolation and stored procedures. I'm pretty sure pg has the same lame transaction isolation issues as well.
Whatever transaction isolation issues PostgreSQL might have, I guarantee you it doesn't have the "same lame" ones as MySQL.
As just one example: "range locking". Look it up.
the biggest one for me is the lack of support for nested transactions
Which you can effectively accomplish in PostgreSQL with SAVEPOINTs. In fact, with those, you can have arbitrarily complicated nesting of "transactions", though that does start to smell a bit like a foot-gun pretty quickly.
http://www.postgresql.org/docs/current/static/sql-savepoint....
What do you mean Postgres has tx isolation issues? The entire point of preferring it over mySQL is that it does most things around that area properly.
not from my experience. last I checked, neither one of them supports nested transactions
Care to serve something more substantial than just a summary of your opinion in a flaming manner?
* A list of advantages vs mysql? (Bonus if you can admit faults of MSSQL as well) * Some blogs or articles perchance? * Performance metrics or % of SQL standard it implements vs the accused?
I'm genuinely curious if it is good but one half-screamed pledge is hardly trustworthy.
I mean, i think most people might agree. it's the pricing that's pretty different though. :)
sure, and I've never used mssql for any project of mine b/c it is so expensive. I've only used it when someone else (a client) pays for it. That still doesn't make it functionally worse though.
I find mysql to be very immature: transaction isolation is a joke, stored procedures are a joke... etc.
I agree it is better than MySQL, but you pay for it. Using MS SQL has heavy licensing fees.
PostGreSQL kicks both of them into the trash.
Okay... now setup a cluster of three pgsql servers with automatic failover... your options are to become very intimate with your dbms, and now pick from half a dozen poorly implemented solutions, or pay licensing costs to EnterpriseDB close to the same costs of MS-SQL, where you get to click a few buttons and your db is clustered.
It is a very big deal... and an area Posgres is sorely lacking, but progress is made, and in another 2 releases may catch up to MS-SQL 2005.
I love what pg offers for dev, but it really isn't enough from the operations side. That said, I'd be more inclined to reach for RethinkDB for most situations these days, if it were up to me.
I have used both and I agree. Obviously, you still wouldn't want to use MSSQL for personal projects but technically it is years ahead of MySQL that's for sure. My main OS is Linux, fwiw.
If I were hosting something on azure (have a smallest windows vm running for some old personal stuff), I would consider it... SQL Express is pretty functional, and the Azure SQL option is nice enough...
I've been leaning towards nosql options for a while though... imho RethinkDB is one of the nicer options out there for most use cases... ElasticSearch and Cassandra are also great options depending on your needs.
innodb has four levels of ACID-compliant transaction isolation. what's your complaint?
Are ALTER TABLEs transactional yet?
Just checked, and the answer is "nope." Have fun debugging your migrations!
Unfortunately, no DDL statements can be transactionalized on MySQL, and that is unlikely to change in the foreseeable future.
MySql is a joke and always has been. I blame a huge majority of the RDBMS hate on the fact that many peoples only experience with a RDBMS was MySql. The issues are numerous, but two of my personal favorites are silent data truncation and allowing 'indeterminate' results with non-aggregate or non-functionally dependent columns in the select[1]. 5.7.5 finally changes the default behavior of the former.
This site lists many of the issues: http://grimoire.ca/mysql/choose-something-else
[1] http://dev.mysql.com/doc/refman/5.7/en/group-by-handling.htm...
There would be no data truncation if you enable strict mode (sql_mode = 'STRICT_ALL_TABLES'). Indeterminate results appear only if the column values in a group are different. SQL standart doesn't allow such selects at all (even if the values in the group are the same) so you have to write longer queries.
MySQL is not that bad, it was used in facebook and wikipedia.
Strict should be the default for something that stores your data. The SQL standard does not allow selects like that for a a reason. Indeterminate results are almost always bad for something that stores data. MySql is that bad [1] and was only used by people who knew nothing about databases to question all of the dumb things MySql did. I'm so happy postgresql is finally getting popular.
FB also uses php, so appealing to it being used is no argument.
As I commented in the parent: it is the default. It was enabled for new installs in MySQL 5.6, and all installs from MySQL 5.7.
Both of these behaviors you describe are no longer the default in MySQL 5.7 (strict_trans_tables + only_full_group_by).
Certainly it's the right direction, but, you have to wonder about a company that took until 2016 to realize that Linux was an important platform to support for an enterprise RDBMS.
It might have hurt them, we'll never know. But they made it until 2016 with that attitude, so it's not like they _needed_ to realize anything.
They certainly realized it many years ago, but they also sold the major competing OS. I'm sure it was a huge battle with the Windows Server team to get this done.
They've known Linux was an important enterprise platform for decades - they just didn't want to admit it openly or contribute to its success.
Decades? Linux was a bit of a blip in 1996.. FreeBSD on the other hand was clear competition at the time.
I think they ported to Linux because Linux is being used by startups instead of Windows Server and they wanted them to use their SQL Server database instead of MySQL or PostgreSQL so they can sell tech support for SQL Server.
Keep in mind that Microsoft sells tech support to companies with a special hotline they can call and get answers and support for enterprise level software. Porting SQL Server to Linux means more copies of SQL Server being used out there and more tech support phone calls that companies pay for.
With Office 2000 there was the MSDE on the CD-ROM that had a developer version of SQL Server that could run on Windows 2000 Pro to test out databases without using Windows Server. It was limited in number of connections and other things.
Can't speak for others... but I'd definitely be inclined to reach for MS-SQL server before any other commercial SQL option (including EnterpriseDB).
That said, SQL is rarely the first tool I look for regarding my DB needs.
I think it was more about a certain bone/bald headed CEO being stubborn.
Ten years ago, Windows was a major component of Microsoft's revenue. They felt they needed to protect it. Today, it is not huge (and the enterprise cloud is). So the decisions at the time and now make sense. Microsoft is becoming IBM.
http://www.computerworld.com/article/3041378/microsoft-windo...
Have they released anything consumer-oriented on Linux yet?
There was an announcement a few weeks back about their Python JIT VM that they're developing, which is currently only for Windows but they say they're planning for other operating systems as well: https://blogs.msdn.microsoft.com/pythonengineering/2016/02/1...
And also a few months ago they posted to the Django developers mailing list about developing MSSQL as a first-class database for Django: https://groups.google.com/forum/#!topic/django-developers/Fb...
It seems pushing MSSQL for Linux is the next step.
Meanwhile, I hope they can get things running ported to FreeBSD, since that's what I use for the server.
VSCode which is really a nice shell for electron. Other than that, not too much comes to mind.
Electron isn't an editing component, it's the combination of Node and Chromium that sits under VS Code and Atom and a whole bunch of other apps, many of which have nothing to do with text editing.
shell implies vscode wraps electron, i'm not sure what your statement is clarifying further.
Sorry if there was a misunderstanding, I've seen a lot of people who seem to think that Electron is the "text editor" and that Atom and VS Code are just different "shells" built on top of it with Github and Microsoft branding.
Some of us remember Internet Explorer for Unix, AND it's sudden disappearance. Or FrontPage Extensions for Apache. Microsoft LOVES to ANNOUNCE things like they've solved world hunger or something, but then things die on the vine, and they get only a smattering of updates, and the docs get really stale.
I'm a 20-year Linux fan, but my main project right now is running on SQL Server in Azure. I've got a side project running to convert it to Rails using the tiny_tds driver, but I'll wait for a couple/few years and see how this REALLY works out.
The more Microsoft tries to brand themselves as "loving Linux," the more I'm getting suspicious. If they really want to wear that crown, then they need to release Office for Linux, in DPKG and RPM formats. The product matters a whole lot less these days, in this cloud-based, app-driven world, but that's the ONE thing that would actually prove it to me.
Other than the CLI tools others mentioned before no. But they have started to treat OSX/iOS as first class citizens which is awesome. Shows a huge culture shift over there in Redmond.
And Visual Studio Code
What CLI tools are you talking about? Can you please clarify and or provide a link?
They were likely referring to the cross-platform .NET Core stuff: https://github.com/dotnet/cli
Kind of - Skype. Although it was released before MS purchased the company and since then it hasn't been maintained very well.
Maintained so poorly that we get this:
Skype on Linux feels a lot more like "legacy product MS inherited and then ignored" than "hot new product under active development."
Skype on Linux seems to have different experiences for different people. For example it is rock solid for me, and always works well. I don't remember any crashes. But it also essentially never gets updated.
I have colleagues on Windows, Mac and iOS where skype is getting updated, but it mostly seems to frustrate them by having an unpleasant user experience. Just today I was sharing my screen but they couldn't actually find it in the skype user interface!
This is Microsoft's business to lose. But network effects mean you have to keep more of the audience satisfied because excluding people means they take themselves and those they interact with away to an alternative.
So basically SQL server on linux is supported until the project isn't fun to work on anymore which then it will be left to rot and eventually support dropped entirely.
I'd say it will stay as long as commercially viable, which it very much is... I'd imagine a lot of this effort was to get SQL services on azure closer to the metal than running on top of Windows.
I don't think it's going anywhere for a while... and I rarely trust MS with anything cross platform.
They released many applications for Android, ever their own launcher.
When people say "Linux" in a context like this, they usual mean "a typical GNU/Linux distribution", not "anything that happens to be running the Linux kernel"
Why not? It's the best enterprise db available
It's taken a ton of years, but here we are:
"If Microsoft ever does applications for Linux it means I've won." -Linus Torvalds
Everyone already knew linux for servers is winning.
Outside of Silicon Valley, it's not so cut and dry.
Could you take a more nuanced and defined stance? What sectors, markets, or users are you referring to?
Virtually any major corporation will have major installations of AD, File Servers, Print Servers, etc using MS infrastructure.
I'll chime in; for me this is a god send. I currently work with a client who specialises in working with automotive companies (Ford, Renault, Peugeot etc), and it turns out that automotive companies love MS SQL. The stack I'm working with is a Java/Linux stack with a Windows/MSSQL backend, simply because it didn't scare the customer as much as Linux/Java Linux/Postgres.
It looks like as an industry they are starting to loosen up a little now, but those MS SQL databases are going to be around for a while, and it'll be nice if I can at least standardise onto a single set of skills and install patterns for the platform OS.
The Seattle market tends to use Microsoft a lot.
And since running those Linux servers in Azure results in revenue flowing to Microsoft by the hour, it seems that MS also winning here. The cloud market share of Azure vs. AWS is however a different dogfight.
MS has been making apps for android for sometime
For years I told my boss: "I'd love to use SQL Server like you suggested, but it doesn't run on Linux".
Now I'm finished.
Can someone tell me why I would want to use SQL Server when there are so many robust and free RDBMS available on Linux?
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'm really happy to see this.
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.
typically the oldest part of a business that's kept around in its current form is the database which stands as the point of record.
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.
Does the server have access to the linked server's statistics?
http://www.benjaminnevarez.com/2011/05/optimizer-statistics-...
> 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
Is there a good reason for this? I can't think of one.
I think a lot of such nonsense is going to go away very soon.
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
Which are super awesome!
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.
You may want to look at the OPENQUERY syntax, which may help to resolve performance problems related to remote joins.
Edit: Useful if both tables in join are on remote (linked) server
I solved it by breaking it into two queries in my sproc. Suboptimal, but also done :)
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.
Otherwise I am pretty happy with the product.
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.
> SQL Server feels like the Sears/k-mart of RDBMS. I'll just go to Walmart, thank you very much.
For a non-american, what's the difference between Sears/k-mart and Walmart?
Walmart is the cheapest, often frequented by (or stereotyped as) lower income demographics. Not sure it's the best analogy.
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.
Wonder if the pricing is such that SQL Server for Linux is the exact same price as SWL Server for Windows + Windows
It'd be ridiculous to charge different amounts for a license based on the OS. Has that ever happened before?
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.
I believe Apple like to buy up software and then charge more for it on non-Mac OSes.
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...
For its eco-system, of course. Their BI tooling is pretty well integrated, as well as (comparatively) easy to pick up.
It's an enterprise product. It has orders of magnitude more features than postgres or mysql.
In my experience MS SQL server has a significantly better query planner than Oracle. So that' something to get excited about.
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.
I am pretty sure this will be very well Integrated into Linux on Azure. I se this as Microsoft way of Building af new stack (this time on azure).
you probably wouldn't, but there are lot of people who run sql server today who would love to run it on linux. I used to be one.
I'd presume that integration with ASP.NET (core) is good, so now you can run pure Linux MS web stack.
Enterprise stuff.
Because features!
I'm genuinely worried now. I'll have to thumb through the Book of Revelation again, but I'm pretty sure MSSQL on Linux and Donald Trump possibly becoming the next President are two of the four Horsemen of the Apocalypse.
Though this news is pretty shocking, I don't think that the horsemen are nigh until MS releases SQL server under GPL.
If that happens then I'm packing up and heading for the hills, this world is done for.
It will never happen. Somebody needs to pay those engineers who build SQL Server. Maybe when relational databases are a commodity and everything is NoSQL?
> It will never happen.
Some people probably said that about the .NET framework. Now almost all of it (the new stuff anyway, and minus Visual Studio) is fully open source.
Making something open source != making something GPL. .Net is licensed under MIT/X11 I think.
If someone is licensing something under GNU GPL, they are also giving away their intellectual property/patent rights (or what ever they call that) to any software developed in GPL, which Microsoft is never ever going to do.
MIT/X11 license is not giving other developers and users such a patent protection from its original developers.
The framework was not an independently monetized piece of work for Microsoft. One the .Net / J2EE battles were settled, there was no need to keep it closed source.
Not this again. .NET is still primarily useful for developing GUI applications. None of that is available on Linux; only the language and the web stack. And, while most devs think C# is a perfectly usable language, quite frankly, IMHO, ASP.NET and EF aren't even in the running compared to other toolchains for web development on Linux. If MS would make the GUI libraries available, then and only then would it be a game changer.
A) From my equally anecdotal experience, non-HTML GUIs are going the way of the dodo as a business investment. So, "primarily useful for developing GUI applications" citation needed.
B) Modern MS-RSL "reference source license" is now OSS compliant. The remaining difference between .NET Full Framework's Reference Source and what's happening with .NET Core is .NET Core has moved development to the open and Github as primary development platform. .NET Core is the future and .NET Full is "stable".
C) One example: http://referencesource.microsoft.com/#PresentationFramework/...
There's nothing stopping you from using the Reference Source today to build your own WPF fork (or, let's face it, you probably mean SWF). You can even start with Mono's existing mostly-there cross-platform SWF or Moonlight codebases and save a bit of time.
You know why you don't hear about lots of people doing that? I'm fairly certain it is because no one is building cross-platform GUIs in anything but HTML(5) these days.
...or Xamarin.Forms, which is its own beast and a rather different direction.
That happened when they realized that dev mind share is (far) more valuable than tooling revenues.
Not just any Dev mindshare, but that mindshare that translates into hard dollars (monetized through some other means like Azure).
They still do consultancy as well as certify developers and IT professionals, don't forget the books they publish, and other things. I think Microsoft is aiming more towards developers than anything, if you can get developers on Azure even better, it wont matter if they use all available FOSS from you, you're making good income as a result!
Plenty of successful businesses are built around providing support, services or premium features for an otherwise open-source project.
Name one (other than RedHat) that is consistently profitable.
Novell (now Micro Focus)
2ndQuadrant
Yeah, but the economics of those businesses do not scale as well as software.
Does the GPL allow me to sell copies of the program for money?
https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllow...
Yes. Does it create a situation where any appreciable number of people will pay money for copies of the program? No. See CentOS. (Though they may pay money for related consulting or hosting services).
> No. See CentOS.
I'd argue otherwise[1].
Also, as of ~2 years ago, CentOS is just another Red Hat supported project.
RedHat doesn't make that money on software, but on support and consulting services. Nothing wrong with that. But it is still not true that you can reasonably well open source software. People who just want the software will get it for free.
With the unseasonable March temperatures, I actually thought April fools day had crept up on me...
Same ... I genuinely looked at the calendar, while thinking to myself "It's still March isn't it??"
Are you in Australia or it like this the world over?
It is the world over: http://www.cpc.ncep.noaa.gov/products/precip/CWlink/MJO/enso...
Seems like March has been quite warm in the eastern half of North America and Europe - not sure about other places.
Until Microsoft changes its licensing model so that it's not ridiculously expensive, I'll still keep preferring free software over their stuff. But that's something they'll never do.
It's all about finding the right tool for the job. For most, this audience especially, open source relational databases are the way to go. For a lot of big business and government jobs, Oracle and Microsoft are the way to go and having your preferred ops environment makes a big difference. At my first job we had to maintain an Oracle DB connection to pull data directly from the City of Los Angeles. At the end of the day we were out of business without that so we didn't really debate the merits of using it. That job happened to be a Windows shop anyway (most of the company were CAD artists using Architecture software) so it didn't phase the IT ops team.
On the other hand, at my current job I've been in charge of some search tech that's Windows only and being the lone Windows user has been a bit painful. We liked the results it gave us but recently developed our own algorithms on top of ElasticSearch so we didn't have to deal with Windows anymore. The Dev work to switch was more than the cost saved on the license for the old software, so this wasn't a case of open source saving is money on the solution implementation. We really just didn't want to focus on Windows Dev ops. I think this is the concern the SQL Server team had and why they're supporting Linux, especially in Microsoft's increasingly Azure focused world.
Paying for a tool that does the job is one thing. But SQL Server's licensing scheme is so fucked up that I see companies building custom servers for the sole purpose of gaming it (extremely low core count and high clock rates). That shouldn't be the goal of software licensing
I don't think that's really gaming the license. If a fast two core system fits your needs then you only need the two core license. MS is happy to sell those to you all day long. If you have a serious load and SQL Server is key to your business you're likely to have better things to do than try to micromanage your server architecture to save a few dollars. If you're in a position where SQL Server, Oracle, or any other specialized commercial DB is a major cost and you're not seeing a positive ROI, messing with core counts v.s. clock speed is probably a poorer use of time than switching to Postgres or MySQL.
In this niche Oracle occupies the "ridiculously expensive" position.
And somehow simultaneously occupies the "I wouldn't use it if it was free" position.
I wonder if you believe people send Larry Ellison money because of his likeability.
No, it's because the people who pay for it aren't the people who have to use it.
Enterprise software shares this in common with Duplo. The purchaser is often more excited than the user.
I used oracle a lot a few years ago... When I was getting used to it I would compare it to a neighbor that is usually really helpful, but on occasion when you asked to borrow something would hit you with a bat first...
I'm all for paying for great software (whether it's open source or not) I prefer open source however. I love how fast development is moving on Postgres lately.
Good plan. Luckily MOST software, even advanced stuff, can run easily on free database engines. They really are CRUD for the most part.
My income depends on SS but it saddens me when I think of how much is spent on it by applications which could so easily run on something that is free.
Could have said the same thing about releasing on Linux as well :D
Yeah I'm still reeling from reading this headline. My reaction is kind of like that scene in Super Troopers where the kid eats a bag full of mushrooms.
Waking up in the morning looking my shitty code is Apocalypse.
I'm very interested to hear some of the details about how the storage engine was ported to Linux. One of the advantages of SQL Server was how well it exploited the Windows overlapped I/O model for disk access. When running large selects, backups, or restores, SQL Server always uses the full bandwidth of my disk subsystem. When I built a prototype of my application on PostgreSQL (which I would much rather run for its free licenses and more mature indexing), I had to tweak all kinds of things to get it to use the full bandwidth of my disk system and I was not always successful.
The space of applications for which storage bandwidth is a limit on performance but where the overall scale is appropriate for a SQL RDBMS is shrinking every year. Is this even a meaningful niche?
Basically, http://yourdatafitsinram.com/
It's not difficult to mimic overlapped IO using a thread pool, and not that much less efficient either, assuming the pending request count is quite low
For anyone unaware, SQL Server is a 'fork' of Sybase after an agreement between Sybase and Microsoft ended in 1993. At that point, "Sybase SQL Server version 4.2 and Microsoft SQL Server are identical."
Sybase runs happily on Unix, Linux or Windows.
At that point, "Sybase SQL Server version 4.2 and Microsoft SQL Server are identical."
Well, that's 23 years ago...
But even at mssql V7[0], most of the systems had internal rewrites that made them different than Sybase.
[0] - https://blogs.msdn.microsoft.com/euanga/2006/01/19/sql-mythb...
While true, it's a bit disingenuous to say this today. The fork happened 23 years ago, and the two products have diverged to the point where there's probably very little common code left.
As an aside, back in the early 2000s I was using the free version of Sybase ASE on Linux for webapps. It was great; painless to run and manage, and fast. Of course, MSSQL blew it out of the water even back then.
Sybase has not kept their end up to what Microsoft has been pushing in SQL Server. Transact-SQL is nicer on SQL Server and the last time I used Sybase the query planner was problematic to the point of needed to force loads of indexes.
I second that, we had to run a medium sized application on FusionIO cards because Sybase was just terrible at query optimization
We did a lot of monitoring and index forcing. We queried the system tables and go the current query plan for the statements running. We were already on one of the biggest boxes HP built (Superdome) with some fun fast storage for the db.
...and Sybase, which is a descendant of Ingres that also runs happily on Unix, Linux or Windows.
I've used a lot of databases over the past 25 years. From DBase flat files to the Borland Database Engine to MSSQL (pre and post 2K), Interbase / Firebird, DB2, PostgreSQL, MySql/MariaDb, Sqlite and more. I haven't used MSSQL in a few years and had to dive back into it for an integration project. Oh my, I forgot how user unfriendly it is.
I can't call a stored procedure from a select query? Ok, write a user-defined wrapper function. Oh wait, I can't call a stored procedure from there either. Now I know why the consultants use a VBA script in Excel to load data... it's actually the easiest way, ridiculously convoluted as it is, if your logic is implemented as stored procedures.
I remember the first time I wrote a stored procedure in PostgreSQL. It was the point at which I decided I would never willingly choose MSSQL for a project again. If you write a lot of stored procedures / TSQL in MS SQL Server, do yourself a favor and check out how it is done in PostgreSQL. It's an order of magnitude simpler and saner.
Time to invite that girl again for a date (that one that said that hell would freeze before she would accept my invitation).
Errr, how exactly does this work? What's the underlying technology that makes it possible?
I'd like to know more about this too. Data storage and retrieval is such an important and integral part of an RDBMS and the switch to Linux suggests that they've had to tear up a lot of their low-level logic. How well they've done optimizing storage for EXT3/EXT4 seems to be pretty important. It would be interesting to see what's changed and how they managed this.
If past Microsoft is any reference, most of the software is cross platform. It is designed from the start to be cross platform. It's just that they never bothered to actually port it to anything other than Windows.
Of course, bits and pieces might be tied to a platform and the dependency chain might drag other parts down, but overall Windows, Office, etc. generally have some sort of abstraction at the lower level that could theoretically allow porting to any platform.
That's my concern though. When you look at other enterprise-sized RDBMS you find tight integration at the "machine" level. Oracle's storage, for instance, uses "Blocks" which are sized based on the block size of the disk they are writing to. This tight integration at such a low level is part of what makes these RDBMS's fast. I would imagine that instead of running on an abstract layer that can be commonly built across many OS's that an RDBMS like Sql Server would be more tightly integrated with the machine they are running on in order to maximize performance and disk space. If so, I would really love to dig through what that means for SQL server.
Might that not imply that the implementation is relatively little tied to a particular OS? Taking your example, as long as there's a way to get the block size for a disk, there's not much more OS-specific code to deal with -- in particular, adapting your code to the file system doesn't need to be done since the DB will essentially create its own anyway. Similarly, only a few threading primitives need to be used -- the DB isn't going to tie itself heavily to the vagaries of the async IO implementation, which does tend to differ heavily and pervasively between platforms.
SQL Server ships with almost it's own OS implementation, aptly named SQLOS. If I had to guess, the interface between SQLOS and Windows is relatively thin (and just IO, Threads, and Memory Management).
There are a lot of other bits, such as Integrated Security Security, Windows Perf Counters, Windows Event Log, that are probably stripped out.
But I also suspect that that the Linux implementation is based on the implementation that they use for Azure SQL Databases.
SQL Server was a port of Sybase initially. Think of it as the RDBMS going full circle back to its POSIX roots
What language was Sybase written in?
Back then alot of that stuff was C. Hard to imagine Microsoft continued writing SQL server in C.
Why wouldn't they write it in C? I'm pretty sure it's a mix of C and C++. Postgresql is written in C as well, as are most of the SQL servers people use. Or at least a mix of C and C++.
I don't really see many other choices being available. Sure we have Rust, Go and other languages now, but most of the current SQL servers are 20 years old or more by now. C is a well known language, there are good tooling, the compilers generate fast code and you can do very precise memory control.
What do you mean?
Well presumably SQL server is written in C++ talking to Windows APIs. The Windows APIs aren't present on Linux except through projects like Wine and presumably that is not the basis of this code.
The three best Microsoft products are their natural keyboard, the mice and SQL Server. Now all of them work with my OS.
> The three best Microsoft products are their natural keyboard...
The Natural Keyboards [0] have been getting less and less durable as the years go by. My first one lasted for ~five years. My second, two or three. My third is less than a year old and already suffering from intermittent failure to register keypresses, as well as surprisingly rapid breakdown of the faux leather material that covers the bottom portion of the keyboard. (The faux leather breakdown is a first for me... all the other keyboards suffered mechanical failure long before I saw any sort of wear on the bottom portion material.)
[0] Specifically, the MSFT Natural Ergonomic Keyboard X000 models that have the stupid, useless zoom slider.
I said they are the best, not that they are still very good ;-)
But I agree with you. My next one will be a kinesis.
> ...they are the best, not that they are still very good...
And I agree with you on both counts. :D
Are you thinking about one of the models with the bowl curves for the keys? If you are, have you typed on one? If you did, what did you think of it?
I did, and it's wonderful.
It's tough to adjust back to a laptop keyboard, however. And switching regularly may create new tissue in your cerebellum.
I really want the wireless natural keyboard with a built in number pad. I know it's seperate but it's not the same.
But the baseball mouse really hurts my hand; and I tried using it for a month before giving up.
IMO the best MS product ever created is Excel.
I'd say their highest point in software was Xenix, but I'd get downvoted into oblivion.
I never thought I'd see this happen, but it turns out to be quite a pleasant surprise. I know it's already possible to run ASP.Net on Linux via Apache, so this is the next logical step.
I'm quite impressed by the possibility of running SQL Server on Linux; as a T-SQL developer immediately out of university, I have come to appreciate its speed and efficiency. It's not perfect and it does have its annoying quirks, but in general it's quite a sturdy RDBMS. MySQL has demonstrated some much more WTF-y quirks (try inserting a varchar into an int column!) and there are places I prefer T-SQL syntax (e.g. temp tables). Management tools don't really factor into it, you can get third-party tools that support intellisense etc. on different RDBMSs. In short, I would have few reservations about using SQL Server for my own projects (since I run exclusively Linux at home).
Licensing is another story though; I dread to think how much it'll cost, but this is a pretty amazing step in the right direction, adding to a recent history of such steps, for Microsoft.
The first thing that comes to mind with this announcement is about SQLServer drivers for non-Windows platforms. Years ago, it was all but impossible to talk to "DataCenter" SQLServer from anything but Windows. Apparently, the connection URI was a configuration endpoint and the driver was responsible for switching between active masters. This meant that a simple ODBC driver wouldn't work as there was no real endpoint to connect to. A real Linux driver would be great; an open source one would be outstanding!
NOTE: This type of thing is what made me hate Microsoft for so long, and even today I find it difficult to recommend them as a solution provider for anything, on any platform. So, while I'm trying to give them the benefit of the doubt, I'll continue working to move everything I can, including databases, to another platform.
Seems quite insular to call it just "SQL Server". We already have Postgres SQL Server, MySql SQL Server, etc. They should call it "Microsoft SQL Server".
They do but they also seem to own the trademark to "SQL Server":
https://www.microsoft.com/en-us/legal/intellectualproperty/t...
No, it's just PostgreSQL and MySQL. Neither has "Server" in its name.
I have a lot of negative feelings about Microsoft because of the historical baggage but they have some good products and technologies. I am also fairly negative on Oracle but when they released their database on Linux it was important for me at the time as it gave a boost to Linux server work (now with added DBA).
There is a lot of software that targets a limited subset of databases due to SQL incompatibilities/features and sometimes that is a subset of one. Getting some of those backends on Linux would be nice for people who have concentrated on unix/linux skills to the detriment of their Windows knowledge.
This eats Windows OS sales to some extent but I am sure they can make it up with database licenses and market share if they take the product seriously.
I've always had this question and this looks like my chance to ask it. If you are developing new software today why on earth would you use SQL server? Is the price tag justified over the many free and open source alternatives?
This would never happen if Steve Ballmer was still alive.
This is huge and I wonder if this now means that they'll also bring other products to Linux such as Microsoft Power BI. It would definitely make sense in light of this announcement.
Every time there's an announcement like this, I like to remember back to the campaign of FUD that MS peddled against Linux. I think Ballmer once called the OS a "cancer".
This is really exciting. I choose Postgres for side projects and new consulting work.
But there are often times when you just don't have a choice. Sometimes it's SQL Server or bust, and you have to work with it. Hell, sometimes, it's MySQL, and you don't have a choice.
I don't hate it at all. I wish it had more of the PL parts of PL/SQL because that would make my life sometimes easier.
I had to implement some very crazy/stupid statistical procedures with SQL Server. It kind of sucked in ways that would have been a lot better in Postgres.
Lots and lots of fun with dynamic SQL where you're stuffing SQL into variables and interpolating column names from variables into those strings.
It was awful. But it worked.
If SQL Server would bring in even some of the PL features of Postgres or Oracle, I would use in a heartbeat.
The tooling that MS provides for SQL Server is second to none. I love me some open source, but the tooling we have available for Postgres and MySQL is just absolute crap compared to SSMS.
Is Microsoft deliberately trying to end Windows as a back end server? What is the underlying strategic outcome that makes this a good idea for Microsoft?
BTW if you reply to this comment with a "Microsoft smackdown" comment then your comment is not very interesting.
I'm interested to hear some thoughtful replies, not Linux fanboy pile-on and jeering.
Increasing interoperability may increase their Windows server share rather than reduce it. One hypothetical: a dev starts a new project. He's got a Windows box and loves Visual Studio, so he starts there. VS makes using MSSQL easy, so he uses it. Previously he wouldn't have because he figures they'll probably deploy on Linux because that's what everybody does.
Come deployment time, they decide to deploy on Windows to minimize unnecessary differences with their dev stack and there are better deployment tools for MSSQL on Windows than on Linux.
An impression I have is that it's still easiest to spin up a simple cheap Linux box on many of the server, VM, and "cloud" providers out there. Open Stack for the most part has avoided the question of Windows Servers. Even (especially?) Amazon's EC2 has supported Windows Servers for a while, but it still has heterogeneous pricing from Linux and fewer options...
I don't think Microsoft is trying to stop people from using Windows as a back-end server (especially when you look at efforts like Windows servers as Docker container farms), more that they are trying to even further lower the barriers to entry that a small "garage" company can spin up something like SQL Server. Maybe as that company grows past the "cheapest VPS on the market" phase they look to running their own Windows servers or (I presume, better yet to Microsoft) let Azure manage SQL Servers for them...
That said, they'd still have to come up with a much cheaper license for SQL Server to entice that "cheapest VPS on the market" crowd, but certainly this appears a step in that direction.
Saw it pointed out in other comment threads too that SQL Server on Linux makes it possible to Docker-ize a full application stack with .NET Core today, while you wait for the eventual promised Docker support for Windows containers... This also seems a possible motivating factor.
Presumably they are finally realizing that Windows more or less ended as a back end server a decade ago, and are trying to keep it from dragging other revenue-generating products with it.
I've read a few times that Microsoft is actually making quite a lot of money with Linux, offering services around it etc., a quick google search just have me this (though a bit older): http://www.wired.com/2015/09/microsoft-built-linux-everyone-...
Is there any point in keeping it alive?
Is it actually used by a meaningful amount of people and businesses?
Yes, it's very common in enterprise scenarios and with regular SMBs.
When was the last time you were in the office of a medium or large company that did NOT have an AD domain?
I'd probably guess its the most popular enterprise os excluding web hosting.
On average I've seen better windows server setups then Linux setups simply because windows servers tend be used in 'enterprise' solutions.
Absolutely, it still brings in billions in revenue each quarter.
It's already over, they're just trying to reconcile.
I'm especially excited for asp.net core on GNU/Linux.
Maybe this is meant to fight off postgres and -- more importantly -- Oracle.
I don't get many predictions right, but 3 years ago I stated to a group of colleagues: "By 2019, Microsoft will be the largest open-source software company on the planet." Yes, I deserved the laughs I received.
Not sure about the accuracy of my prediction, but I'll bet I'm closer to right than wrong by that time.
I remember when Oracle became available for Linux - that was the beginning of a new era in terms of the legitimacy it conferred on Linux. (Yes, I know, Oracle the company sucks, but that's tangential to this particular discussion).
I wonder if this is the beginning of a similar change in the industry.
Someone page Vinod Valloppillil[0] for a quote on this one. Anyone know if he's still in the industry?
I just started a job where mssql is used extensively. They're trying to get a PHP 7 application off the ground and the lack of a mssql driver (non-PDO) for PHP 7 is a big pain point. As of Jan 2016, they had released a beta release and were taking a poll on what platform they should support next (I'm not kidding, the entire history is here: https://github.com/Azure/msphpsql/issues/58). Unfortunately it seems support is secondary in this case to Microsoft, as they are unable or unwilling to allocate the necessary resources
Why are they avoiding PDO? Seems like that's what people should be moving towards in terms of flexibility and security.
That struck me as odd too (I'm not really up to date on php7, and haven't considered php on windows in at least a decade). But perhaps it's because the PDO-driver is built on the old TSQL-interface, and MS own drivers haven't been ported to php7 yet (not with a stable release, anyway) ?
http://php.net/manual/en/ref.pdo-dblib.php
I've used and liked PDO myself in the past. The issue is that even though the application would pretty much simply run on PHP7 (since it runs on 5.6 already) if MS had a compatible driver instead of contemplating a re-write
Maybe my secret hope of Exchange on Linux isn't completely insane after all...
If Microsoft really were to "love Linux," this would happen. Feel free to gauge their marketing/PR sincerity in light of this. This and Office are really the only 2 things Linux really needs from Microsoft. Everything else is taken care of. I mean, SQL Server? That's fine, but, if you really needed a terribly-expensive database server running on Linux, we've had Oracle for, like at least a dozen years now.
I wouldn't hold my breath. I'm guessing this is more tied to the .Net moves to Linux and getting their full web stack on Linux. Though if their long term strategy is to give up Windows Server, then everything may come to Linux.
IIRC Exchange depends on Active Directory. I would've thought porting AD to Linux would be a huge undertaking, but then again I would've thought the same about MSSQL, so like you say maybe it's not so insane.
Don't see that one happening. Exchange is too tightly coupled with Active Directory and IIS.
I don't think Exchange uses any interface other than LDAP to hit Active Directory, so I'd think there's at least a fighting chance that the AD requirement could be satisfied by other LDAP servers.
I can't speak to the IIS integration anymore-- I quit following that at a low level back in the Exchange '03 timeframe. I would suspect there's a clear line between IIS and Exchange, however, that could be used to facilitate an adapter layer for a flexible HTTP(S) server like nginx. The SMTP, POP, and IMAP services, though, would probably involve a lot of re-implementation.
Last time I checked it also uses a lot of RPC protocols, e.g. NSPI.
> In-memory database support for every workload with performance increases up to 30-100x
Can't wait to try this one, a Redis-like service with all the consistency of a mature SQL database (in theory at least).
Don't get me wrong, I've being deploying Redis in production and I'm love with it, but it's nice to have an alternative with referential integrity not to mention the "isomorphic" effect (you'll be able to switch from non-volatile to volatile persistence without the wizardry required by the typical in-memory databases).
I wonder if SSMS tools are going to go crossplat like VSCODE?
How great would it be to have first-class sql-server-management-studio on your Mac/Linux desktop?
I wonder if SqlExpress is going to be available on Linux too?
I find this really weird for the following reason.
Only cost conscious developers care about running db server on the same machine as application server to keep costs low. Such people wont buy SQL Server at all for the cost related reasons.
Non cost conscious developers can always run SQL Server on a separate Windows machine while keeping their application servers on Linux.
Except Microsoft intends to make SQL Server free and make it replace Mysql among small developers and later help them buy SQL Server instances in cloud and make money.
Microsoft, you devil! That is awesome news. It will definitely push others to up their db game. One thing is DB engine, other is a suite of tools that goes along with it.
I really love developing on sql server, but...
From memory I remember when they "acquired" the source from Sybase and one of the selling points was that they could strip out all the multi-platform complexity from the source code. Being windows-only meant it was simpler, less complex code, faster and less buggy.
It also confuses my view of what MS has been doing. Maybe Azure is more important than Windows now? Its going to be kinda weird to see SQL Server on Linux in Azure.
You're not thinking like a businessman. That purchase from Sybase 23 years ago and this announcement today have no technical justification. They're business decisions. The technical aspect is just a cost of doing business.
Their bet evidently is they can make more money selling SQL Server without Windows than with it.
They took the former vp of Azure, and made him the CEO. Microsoft is very serious about Azure.
It's simple: we're living in a heterogeneous computing environment now and Microsoft cannot ignore that any longer now.
> Being windows-only meant it was simpler, less complex code, faster and less buggy.
So you don't think that, maybe-just-maybe, it's gotten a little easier to write cross-platform code in the last twenty-three years?
I'm pretty sure someone born when they acquired the source to Sybase is now old enough to vote.
This is another awesome piece of news!
If you're interested in using docker+.NetCore+EF a "proper" database was the only piece missing.
What's EF in this context?
Entity Framework. Microsoft's high-level ORM for .Net.
Entity Framework
postgres is still a "proper" database.
Sorry, you're 100% right and I agree with you on that.
however http://www.npgsql.org/ is not yet a "first class" driver.
Notice the tags on there, "Stable" release is inaccessible and unstable has warnings (also it is labelled as unstable)
I would be less likely to feel secure in trusting the unstable release of a third party driver even though I know that the .NET team mentioned NPG during the last community standup. My understanding was that they said members of the Entity Framework team are working with the team at NPG.
I do think that it will be usable very soon, but the SQLServer drivers are working now.
I have some experience experimenting with NPGSQL and it was definitely not production ready; huge performance problems and general issues abound.
I wish someone would step up and write a better .net postgres driver.
Awesome :) Now a days Microsoft changed a lot, welcome to the new world (Linux). The raise of NoSql, how MS SQL survived ! amazing.
Does anyone know if this potentially includes a replacement for FreeTDS. A replacement would mean open source in this context.
Scroll down on this page for more information on client drivers: https://www.microsoft.com/en-us/server-cloud/sql-server-on-l...
De SQL Server Native Client on Windows supports many features [1], most of which are not supported with aforementioned non-windows SQL clients. JDBC & Linux ODBC support a few High Availability features (with try/catch). JSON, Ruby and Python seemingly support only basic connections.
What are the effects of this? Does anyone have experience migrating SQL Server clients away from Windows? Do Oracle, PostgreSQL, MySQL or others have database-clients with more rich feature sets? Or are these Native Client features barely used and not missed on non-Windows clients?
Sadly not open source and no ability to use it with CentOS 6.
Support for RedHat 5, 6 and 7 so it'll work on CentOS 6 which is re-packaged, de-branded RHEL:
https://www.microsoft.com/en-us/download/details.aspx?id=364...
Can't really help you with the open source side of things.
They mentioned a preview available today, but I'm not seeing it on the Partner or MSDN portals. Anybody got a link?
At the end of the article (although it's not stated, and the link was down about when this was posted): https://www.microsoft.com/en-us/server-cloud/sql-server-on-l...
Thanks for the assist, looking forward to testing this out.
Having worked as a Windows admin for the the past three years, the one piece of Microsoft technology that never gave me the least bit of trouble is SQL Server. It's expensive (compared to the € 0,- price tag of PostgreSQL), but otherwise I like it very much. It will be interesting to see SQL Server on Linux.
Even as recently as a year ago this would pass as a great April Fools joke. Boy how have the times changed.
I don't really know why I would choose to use sql server if I wasn't already locked in to MS as a vendor. Is the idea that it gives people the ability to move away from MS if they already have vendor lock in? Or is it to hopefully compete against eg Oracle.
I am incredibly excited. This is the first step towards a docker version of SQL Server which for our company would enable us so many options to improve developers lives. Even if we stay with Windows for production SQL deployments, this will make development awesome.
In the sign up page (https://www.microsoft.com/en-us/server-cloud/sql-server-on-l...) you'll find this quote: "Please note that at this time, SQL Server on Linux is available on Ubuntu or as Docker image." :)
Wouldn't Docker for Windows (in preview for many months now) count as the first step?
What do you expect Docker to do for you (in development) that you can't already do with SSDT and LocalDB?
The reason this has my attention is because 'R' is being integrated into the engine.
Never really found a GUI I liked as much as MSSQL (not that you always need it, but it's nice!) - though I'm really in love with postgres - I've sometimes found myself just thinking "why doesn't everyone do it like this".
Why Microsoft needs SQL Server on Linux http://www.zdnet.com/article/why-microsoft-needs-sql-server-...
Is SQL Server Management Studio available on Linux? Is there anything like it on Linux?
MSSQL actually is really mature and performant (on par with Oracle) and I'm interested to see some benchmarks vs MySQL and PostGRES. I think it could become the replacement for SQL enterprise, even over the widely loved PostGRES.
Don't hold your breath. The EULA for SQL Server prohibits publishing benchmark results.
It's not completely self-serving. Back when magazines were made of paper, "DBMS Faceoff!" articles sold a lot of copy, and generated more heat than light. A DBMS is a complex beast, enough so that it's impossible to say if X is faster than Y for all workloads.
Just the other day I was discussing with some folks that Microsoft has made an amazing effort of the last two years to win back the hearts and minds of developers. This is another great step in that direction.
Just have to say, it is great to see Microsoft turning again into a software company! Even after all the hate, they do great products and good stable software. A great example of a successful software company.
I wonder if the UI management tools will be web-based like GCloud/AWS/Azure, or if they will be OS-specific. Still, it's very impressive that Microsoft is moving outside its own OS.
They'd have to be web-based, surely.
this will make it much more available to containerized stacks for sure.
Can't wait to see benchmarks of this on same config hardware :D
I've always enjoyed using SQL Server and I'm really happy about how it's grown over the years in features and performance. I really never thought this day would come.
Ok, good. Now how much a SQL Server on Linux license is going to cost ? Does it mean businesses using Linux will now be subject to Microsoft license audits ?
Oracle runs on Linux. Oracle is a member of BSA. If you use oracle on Linux you are still subject to audits. Why would this be any different for Microsoft.
The question now is, will they offer up a free edition to compete with MySQL? And when will they open-source it?
(I can't believe I'm actually saying that.)
There is a free (but not open source) edition and it's been available for some time. SQL Server Express. It has very severe limitations though, which make it difficult to recommend.
Depends on the use case. A local POS vendor is running most of their local databases in stores (1..10 registers) on the Express version. Not sure how often they archive data out of the main database, though.
There is SQL Server Express though it has a 10GB limit
With this trend, I will not be surprised if Microsoft releases its own Linux distro which will be optimized for MS software (e.g. sql server)
of course, the major downside to this is that linux admins will now have the possibility that they have to work with sql server
I bet a lot of Microsoft's push to Linux is that something like 98% of the internet runs on non-windows OS's.
May not have been as hard to port as you all think. SQL Server was a port of Sybase, which was *NIX based anyway
Pretty sure the code has changed enough in 23 years that this wasn't relevant.
very interesting move strategically.
would I use it for my own project's? no.
would I use it for some random software that requires mssql? yes.
Very happy to see this.
MS is extending the olive branch in so many ways, and we in the open source community can learn to forgive. Still, it will be hard to get over the mutual hostility from decades past.
http://www.huffingtonpost.com/trudy-bourgeois/what-george-wa...
So what's up? Why do you disagree?
Now if they port Microsoft Office, we'll finally be able to say: "hell hath frozen over".
Well, it wouldn't surprise me, because look at the work they're doing to support Android.
Just because it's possible doesn't mean it will happen. Office is on Android because it has a huge market share.
Linux desktop still is very low market share so an Office client doesn't make sense there, whereas Linux server is high market share so SQL Server does make sense.
not gonna happen, office is pure client technology
I'd say that it is unlikely, but I wouldn't call it impossible. Most of the recent moves out of Microsoft seem to point at a large strategic shift, away from Windows. In the past the Windows division had an iron grip on Microsoft, it seems to be loosening (see .Net port, VSCode, etc.).
Wow. Just two days ago we were wishing SQL was available in Linux so we could move away from Oracle.
I wonder if i can run EF on Windows with a SQL Server backend now?
What would be the memory usage difference?
Doesn't EF just use an ODBC connection? I can't imagine that the OS upon which the Server is running would have any effect on something as high up the stack as ODBC/OLEDB.
ADO.NET, not ODBC.
One of the few usable products MS has (haven't used it since SQL Server 2000 though).
This could reduce the cost of using SQL Server on AWS if Amazon supports this flavor.
Good move. It's just late.
Here is the obligatory admiral ackbar link:
https://www.youtube.com/watch?v=4F4qzPbcFiA
With that out of the way, I wonder if they will port their other software like Mcrosoft Visual Studio, Microsoft Office, various games, etcetera.
A few years ago, I would have though that somebody posted this three weeks early.
Oooh, I can't wait to ignore Microsoft products on Linux as well!
PostgreSQL for me thanks.
Using SQL Server on Linux would be like swearing in church silly smile
How long until Microsoft put out their own BSD distribution?
They have their own Microsoft Linux, but it's for Azure internal use only.
Thanks, I'd missed this. http://www.theregister.co.uk/2015/09/18/microsoft_has_develo...
Well, back in 1980s, Microsoft had its own UNIX system called Xenix. It was not BSD, but it incorporated some programs from it.
How long until the memory of the last antitrust action by a major government fades?
Never. Microsoft could open source Windows and on HN and elsewhere you'll hear the same tired memes.
I can't wait to try this in the FreeBSD Linuxulator!
We havent seen the sources yet but with some luck we will be able to get it in ports without the need for linux kernel emulation ;)
This is huge, competition for Oracle increases. :)
Checks calendar , hurmm it's not April 1st ... ?
Wait I remember sun one asp server .
Please tell me this isn't sql server written in c# using mono !
Gob-smacked.
This is absolutely amazing
hehe, No thank you
if you can't fight them, join them!
Isn't it too little and too late?
It would be more beneficial for whole community to contribute to Postgres.
We already have fairly superior commercial solution, like Informix Dynamic Server family, which is superior in everything, except compatibility with MS, that lost "competition" (to meme-based popularity) to crap like MySQL or bloatware like Oracle.
This is, again, good publicity and excellent PR action, but my bet is that performance and especially stability will be poor, like it is with .Net port or Skype port. To bring a server to the market requires expertise with target platform which very few UNIX shops has.
Open sourcing IDS, which has remarkable technology inside, which is partially related to Postgres, would be a much better move.)
Hey there! I'm trying to learn about this stuff , would anyone pls help me out how to be a hacker?
If you mean hacker in the sense that you want to learn about breaking into computers, then you've come to the wrong place.
Hacker news is a startup/technology oriented news aggregator with a comments section.
Not a den of criminals. (depending on your views about capitalism i suppose)
Looks like they announced this 3 weeks early.
could you clarify? I don't get the reference.
It's a reference to https://en.wikipedia.org/wiki/April_Fools%27_Day .
Three weeks from now is April Fool's Day.
As in an April fools joke
I was not expecting that at all.
`Please join me Satya Nadella, Joseph Sirosh and Judson Althoff at our Data Driven .....
Thanks, Scott ` This is why there is a comma in grammar. `me Satya Nadella, X and Y` is different from `me, Satya Nadella, X and Y`
haha i thought I'm reading that microsoft will bring MSSQL to Linux. But I'm just dreaming
Err didn't they announce exactly that?
Hey guys, I'm trying to learn about this stuff, would anybody pls help me out!?
OMG - They'll probably cripple the implementation of this. I wouldn't trust MS on this. It sounds nice, but I wouldn't set this up if it meant we could have world peace...
MS SQL relies heavily on Windows OS API. How are they going to pull this off? With some kind of VM layer running under linux with a stripped down Window OS which will run MS SQL?
MS Should announce that they are going to fork a version of Linux with their brand MS-Linux. Hell - If they port every piece of software over to Linux, they would rule the world & back-end server market.
Any way. Good luck!