Lots of new features...
Probably lots of new cost, in fact, I think the per processor license fee is shown in the article graphic.
Microsoft is releasing a new preview of SQL Server 2016, including integration with the R language for statistical analysis. In April 2015, Microsoft completed the acquisition of Revolution Analytics, a commercial provider of software and services for the open source R language. The new Community Tech Preview of SQL Server …
So, did they fix the optimizer to work on very large databases with vast numbers of files and filegroups?
Thought not.
If MS would just get the basics right, it would go a long way to improving the product.
(I have a long list of sub-optimal and broken features classed as "will not fix" and some of them are incorrect results returned. Still not good enough!)
Ummm, if the capabilities around Very Large databases does not currently exist in SQL Server, then the likely uptake of that capability in the present or in the future is going to be very small. On the other hand, adding such capabilities to Azure would make a ton of sense as you not only have a small chance, versus none with existing VLdb owners, of uptake and there's a real chance of uptake by all the players now and in the future in "The Cloud." If nothing else, they may kick the tires to see if a "Big Data" play may make sense and when it does, sign up with Microsoft.
The players in that market have, to date, had trench-lines dug and artillery pointed every-which direction. I can't see any firm porting to another DMBS of any type. Your chances are much higher for any kind of "greenfield" play. Know thy customer applies to potential customers too.
VLDB != Hadoop, NoSQL
I am talking about very large highly structured databases against which SQL queries can be syntactically be defined and which work (i.e. are optimized more or less correctly) for databases which have few file groups. The fact of the matter is that one can have 10s of thousands of file groups and support tables with 100s of billions of rows and the DDL syntax and engine were extended to support this in SQLServer.
The problem is, a simple query might take several days to optimize because the optimizer is a broken piece of shit is such cases. This is not a secret, but MS is completely unconcerned about this fact and dissemble on the subject whenever it is broached in support.
MS has a strategy to support "large databases", but are unwilling to fix the basic functionality required to do so, relying on "check box" functionality that is unusable in reality. These are the facts on the ground!
Moving it to Azure won't solve the issue either, and the sort of optimization problem I am alluding to, and they CANNOT be solved by the addition of hardware.
Down votes are an indication that there are clueless morons in the world.