Microsoft's SQL Server 2014 early code: First look

In-memory database engine, improved integration with Windows Azure, and new indexing technology for high performance data warehousing applications - there's plenty to like in SQL Server 2014, released to manufacturers on Tuesday. But while Microsoft has been busy and done some heavy lifting, the code that will become generally …

[All names Taken]

But shoorli ... ?

... if we are talking about speed that means processing is hardware driven?

So this new release must have its operationally optimised hardware in which to run?

Otherwise if it is wholly/mostly/partly software driven it will run like a dawg?

Se, el Reg,would it be helpful for new operating systems to identify what hardware (eg chip architecture) it has been optimised on?

EDIT: el Reg, the links to articles have some pleasant images worthy of further exploration (76 drawing with person wearing what appears to be a bowler hat) but when I click the link the thumbnail image does not appear in the article if you know what i mean.

[TheVogon]

Re: But shoorli ... ?

The author has missed stacks of new features. For a real list, see here: http://www.slideshare.net/d501159/sql-server-2014-mission-critical-performance-level-300-deck

[donk1]

Re: But shoorli ... ?

True, I am covering almost all of these at SQL Saturday Exeter my "SQL Server 2014 (not Hekaton)" talk.

[Nick Ryan]

I've been wondering what was coming up next in MS-SQL land... but really couldn't summon the self-loathing to look it up.

So... in-memory databases where you can't use some very common SQL statements / operators. Thanks for that Microsoft... play catch up with other RDMSs and just fail to implement anything useful, that just sounds rather too typical.

More stuff for MS-Cloud... not exactly a surprise. Easy backup or sync to MS-Cloud would be useful, except for the pending legal and ethical minefield of exporting data outside of the EU. Would be nice if MS could make features such as these vendor neutral, but we know that will never happen as all they exist for these days is to push everybody onto MS subscription services.

So MS, instead how about actually fully supporting SQL standards, such as those from 1999? Maybe even reducing some of the annoying as hell language restrictions in T-SQL? Maybe even adjusting the management interface so it is easy to find useful information rather than trawling through three or four otherwise unrelated windows full of unsorted and otherwise impossible to filter options? Improving the performance through optimising the software would be nice too: new hardware <> optimisation.

[BlueGreen]

@Nick Ryan

> Maybe even reducing some of the annoying as hell language restrictions in T-SQL?

could you clarify? am curious.

[Nick Ryan]

Re: @Nick Ryan

> Maybe even reducing some of the annoying as hell language restrictions in T-SQL?

could you clarify? am curious.

It's the inconsistencies that are annoying... such as having to explicitly define parameter vars before being able to pass values to a function rather than performing inline calculations in the call itself. In T-SQL There's a whole host of missing of annoyingly limited string manipulating functions requiring slow workarounds (string manipulation in T-SQL defines a new kind of epic slow more accurately measured on a glacial cycle), even down to there's LTRIM() and RTRIM(), but no TRIM() and my "favourite" is the 4k char limit on PRINT (yes, dumping 100k chars out of the terminal might be stupid, but let me do it if I need to please).

When you've developed in as many languages as I have, it's these kind of stupid things in any one of them really annoy!

[BlueGreen]

Re: @Nick Ryan

> such as having to explicitly define parameter vars before being able to pass values to a function rather than performing inline calculations in the call itself

er, eh? Still don't understand. Example?

If I may make the point (if this is related to what you're saying), you *can* define a func that gets evaluated *inline* in a select statement. It's a inline table-valued function. Clumsy but removes the overhead of the call and gives you moderate flexibility.

> [stuff about string functions]

yep, I guess, though never been a biggie with me. Lack of arrays occasionally hits me much harder.

> string manipulation in T-SQL defines a new kind of epic slow more accurately measured on a glacial cycle

Yes. I think from testing that strings are represented as btrees internally. nlogn access, with a big constant overhead.

[Anonymous Coward]

Re: @Nick Ryan

... it's these kind of stupid things in any one of them really annoy

Yes! I thought I was the only one.

SQL Server is all very well (I use it at work), and has the usual "head-line" features, but whenever I need to do something not quite mainstream, but still pretty basic, I do feel it somewhat lacking.

I Google for the T-SQL specific command/function, and there's always a 25 line "snippet" for something that I think should really be built-in. I can't think of anything of the top of my head (and I can't be bothered with nit-picky counter-arguments)... it's just my feeling, and overall impression of it.

My fellow .NET devs swear by it, but when I (un-provokingly) challenge them, it turns out that they just haven't used anything else.

(Personally I have no preference, depends on the job's requirements/constraints)

[SVV]

Nice summary of my main thoughts

Shame some senior executive decided to "go all out for cloud integration" in order to look in touch rather than implement SQL properly for the umpteenth time.

I've used SQL Server in a fairly undemanding application and it was OK, but saw no real advantage over Postgres at that scale (apart from the fact that everyone there was used to it). How it reaaly fares as transactional demands on it increase against Oracle and DB2 is something that I've never had enough concrete information on.

This quote was rather a rib tickler though :

"A copy of the data is streamed to disk for persistence, though you can disable this for maximum performance if you do not care about losing data."

Sitting here contemplating the thought processes of someone who is writing data to a database but doesn't care about losing it......

[BlueGreen]

Re: Nice summary of my main thoughts @SVV

> How [postgres] reaaly fares as transactional demands on it increase against Oracle and DB2 is something that I've never had enough concrete information on.

Nor have I firsthand but I worked with a guy who had and said postgres was good but didn't handle large amounts of data as well as mssql.

> Sitting here contemplating the thought processes of someone who is writing data to a database but doesn't care about losing it......

I can think of 2 good use cases for this.

a) you're doing a conversion of data. It takes days to run. The logging of a RDBMS is a real overhead. If I can disable that I get a real boost. If the DB dies (e.g. power cut, etc.) you just start again. But snce the DB dying is a very rare event and getting the conversion right is repeated iterations of work over months (and then the bastard project gets added to by some incompetent bastard manager, growing it yet more), it's a net win [*]

b) Value of some DBs is in their cumulative mass of data, not their detail. Missing an hour's worth of updates is barely noticeable, missing a day's worth is not a big issue. (Moral: much data is not unconditionally precious; don't treat it all the same way)

I've worked with cases a) and b).

[*] though write-buffering raid cards now mask some of these drawbacks

[Charlie Clark]

Re: Nice summary of my main thoughts @SVV

@BlueGreen

The logging of a RDBMS is a real overhead. If I can disable that I get a real boost…

Sure, so you just disable logging and possibly even transactions or integrity checks (eg. UNIQUE) as desirable. And you run it on a RAM disk if you can't configure cache to be big enough. This has been standard practice for years and presumably possible with MS SQL. One would expect the "in memory" database to bring something more to the party. Presumably for temporary tables as part of expensive queries.

The quip that the next version will dramatically increase the size of such databases is worth reflection. It suggests to me that what is being released now isn't really finished or is dependent upon other components which are also still "work in progress".

[BlueGreen]

Re: Nice summary of my main thoughts @SVV @Charlie Clark

> Sure, so you just disable logging

You can't disable logging on mssql.

> possibly even transactions or integrity checks (eg. UNIQUE) as desirable

What's a transaction check? And integrity checks tend to be cheap compared to logging.

> you run it on a RAM disk

For a *small* db, if you have enough ram. We didn't. Still, will bear that one in mind.

[Charlie Clark]

Re: Nice summary of my main thoughts @SVV @Charlie Clark

You can't disable logging on mssql.

What's there to say about that apart from facepalm?

What's a transaction check? And integrity checks tend to be cheap compared to logging.

I said transactions and integrity checks. Checks only for integrity. I didn't understand from the example why a heap of transactions would be required for what sounded like a materialised view. Much as I dislike them, MyASM temporary tables have always gone like shit off a shovel because they think ACID is a little tablet with a smiley on it!

[donk1]

Re: Nice summary of my main thoughts @SVV @Charlie Clark

(Transactions) or (integrity checks).

Integrity checks i expect are unique/primary/check/foreign key constraints. We used to disable them when doing data migrations until the end.

"You can't disable logging on mssql.".

Pity, you can on Informix!

[Charlie Clark]

Re: Nice summary of my main thoughts @SVV

> How [postgres] reaaly fares as transactional demands on it increase against Oracle and DB2 is something that I've never had enough concrete information on.

Entreprise DB who promote their flavour of Postgres as a drop-in replacement for Oracle have been remarkably frank about this in the past. Many of their customers' requirements have driven the 9.x series which seen serious performance improvements across the board (raw speed but also scalability). Don't know if Postgres is quite there yet. As usual, however, getting the most out of any of these systems is as much about having a good DBA who knows what to tweak as anything else.

[Anonymous Coward]

Re: Nice summary of my main thoughts @SVV

"getting the most out of any of these systems is as much about having a good DBA who knows what to tweak as anything else."

I think you've hit the nail on the head.

SQL Server may look great on paper, but as soon as you let an idiot loose on it, all bets are off.

The DBAs I respect tend to be the ones that know several DBs, and know when or not to use them. Failing that, they have enough knowledge on a single DB to know that it's not perfect.

Unfortunately for MS, the fast majority of SQLServer-only DBAs don't fit into this category.

[I'm a dev working only on SQLServer, dabbled with MySQL before Sun]

[Hans 1]

@ Nick Ryan

I agree, the MS SQL administration software is a nightmare, that is why I use osql - the tool made for real men - know your code or do not touch it. It is the same with everything IT:

You know what you are doing and use the command line

You do not and should not touch it

If you administer enterprise software from a ui it means you should never have been allowed to get close to it. If enterprise software does not have a cli, you should not buy/use it.

[BlueGreen]

@Hans 1

> MS SQL administration software is a nightmare, that is why I use osql - the tool made for real men - know your code or do not touch it. It is the same with everything IT:

osql is superseded by sqlcmd, and your whole comment is stupid snobbery. Try (e.g.) detaching a DB using cli and BOL. Or start a profile trace. Or a million other tasks.

If I need to create a script for reuse/distribution I'll do it, if I need a one-off I'll use mouse+click and just get the job done. I get paid by results, not purity of my sould, so I use the most appropriate means.

Or maybe you were just making exactly this point, in which case, touche.

[Anonymous Bullard]

If you administer enterprise software from a ui it means you should never have been allowed to get close to it. If enterprise software does not have a cli, you should not buy/use it.

That is a highly generalising and elitist comment that goes against the general consensus of most IT professionals.

And I full heartedly agree with you!

[Slawek]

"Easy backup or sync to MS-Cloud would be useful, except for the pending legal and ethical minefield of exporting data outside of the EU"

You do not export them outside of EU, if in Europe you use European datacenters (Azure North or West Europe regions).

[donk1]

Already there is 2012 SP1 CU2 - Backup to Azure via Powersheel, T-SQL and SMO only.

2014 adds backup and restore via SSMS.

David.

[CadentOrange]

Some questions

Is the insert performance achieved by reducing reliability? For instance, on Postgres you can speed up inserts significantly by disabling fsync, which means that a commit operation succeeds before the data is fully written out to disk. The article mentioned that this is now possible on SQL Server but does not mention whether the impressive numbers were achieved by enabling this feature.

Insert performance is only one aspect. Is query performance better? Not just simple queries that hit a single index or the primary key. Queries with multiple subqueries or joins will be interesting.

What about sharding? The cloud is all about scaling out and traditional RDBMSes are pretty complex to scale out while maintaining ACID compliance. Is this on the horizon for SQL Server?

[TheVogon]

Re: Some questions

"Is the insert performance achieved by reducing reliability?"

No.

"Is query performance better?"

Yes - see the presentation URL above.

"maintaining ACID compliance. Is this on the horizon for SQL Server?"

It supports sharding with full ACID compliance across up to 56 nodes.

[CadentOrange]

Re: Some questions

Thanks. I've just seen your post with a link to the features. SQL Server is starting to look interesting again.

[BlueGreen]

Re: Some questions @CadentOrange

Take this from someone who's worked with it for a long time.

>>>>>>>>> If you can avoid mssql, avoid it <<<<<<<<<

It has a lot going for it BUT it's expensive, licensing is a deliberate mess, it's designed to integrate heavily with other mssql tech so basically it's software heroin to get you hooked in deeper and deeper into their ecosystem, and it's not as good in some important areas as it should be - MS is concentrating on making it flash as opposed to making it solid.

Finally, MS is not to be trusted. They *will* use this to fuck you over, eventually.

If postgres is as good as people say, try that first.

[BlueGreen]

Re: Some questions @CadentOrange

To those MS marketing shiills haunting here to downvote negative posts, get this:

I used to think highly of MSSQL. You had a lot of good faith from me. You decided to push for a features at the cost of improving, or even maintaining, the core product (server + its documentation).

You screwed up, taking my goodwill for granted then blowing it because, $$$ (capitalism, fuck yeah).

That's what MS does, it fucks you over. Then tries to use marketing twats to dig its way out of its self-dug hole (ever a fail).

If you want my goodwill back, fix MSSQL and earn my trust. 'Til then my above post stands.

[donk1]

Re: Some questions

Hmm. went to event where I heard more nodes than that being used in the Microsoft cloud, of course at that scale you need to talk to Microsoft first..

[Davidoff]

The recommendation for hardware is two sockets to avoid issues with NUMA

"The other is that “the recommendation for hardware is two sockets” to avoid issues with NUMA (Non Uniform Memory Access) that affect performance."

That doesn't make much sense. Every modern two socket system is NUMA. AMD is NUMA since the very first Opterons (2xx) from close to a decade ago, intel since the Nehalem (XEON 5500 Series) which came out in 2009.

If they wanted to avoid NUMA issues they should have recommended single socket systems.

[Anonymous Coward]

Re: The recommendation for hardware is two sockets to avoid issues with NUMA

I can't find any reference to this requirement. Windows Server and SQL Server are certainly both fully NUMA aware

(SQL Server has been NUMA aware since SQL Server 2000 SP4!)

[Anonymous Coward]

Ohh I mis-read the title.. I thought they were releasing the code for it. Aren't I naive?

It would be cool to (privately) port it to Linux, and give it a real chance to prove itself! C'mom, it would!

Having said that, from what I've seen of MS code... I'd expect better from my Junior (anon so I don't offend her)

[Anonymous Coward]

SQL server has had the fewest security vulnerabilities of any commercial database system consistently for at least the last 5 years.

[Anonymous Coward]

That just goes to show that more features mean more attack vectors.

[Anonymous Coward]

You missed the only new feature most addticts will notice and also the most important one for Microsoft, the pile of cash the upgrade costs.

[Anonymous Coward]

If you have paid for Software Assurance, then it is free....

[Anonymous Coward]

If you have paid for Software Assurance, then it is free....

Hardly free. Just paid for over several years.

[Anonymous Coward]

"If you have paid for Software Assurance, then it is free...."

If you've paid for something, then it's not free.

[Anonymous Coward]

It's no extra charge to upgrade if you have a current support (software assurance) contract. Therefore it is free if you were sensible enough to buy support.

Your point is like saying BOGOF isn't getting one free. Yes you have to buy something in the first place, but the subsequent benefit is at no extra charge is what it means!

[Anonymous Coward]

But the point is, it's more like BOGOATSPOTY - buy one, get one at the same price over three years. Still most definitely NOT free. You can buy SQL 2012 for $x and be done. Or you can buy SQL 2012 for $x and agree to pay $y every year and get SQL 2014 when it comes out. Now, sure, if memory serves, you wind up paying a bit less via SA than an outright new purchase, but it's definitely NOT FREE.

SA was always a gamble - you're gambling that MS will come out with a new version before your total yearly SA costs equal a new purchase cost. At least that's what I remember of it when MS came out with it years ago. Could be I'm remembering wrong.

[Hans 1]

Re: WTF?

> WTF...? No use of DISTINCT, IN or LIKE? So it's practically useless then for any reporting purposes?

"practically useless" is the other name for MS SQL Server.

[Anonymous Coward]

Oh,

Limit ot limited seem to crop up a lot in this review, I thought MS SQL was supposed to be full featured?

[Anonymous Coward]

Re: Oh,

True, but these are V1.00 of significant new features. Expect those limitations to drop off over time.

Stability, security and performance are more important to Microsoft these days than bolting on features that might mean dropping a flaky product out of the door in what is a $1 billion+ market for them.

[Anonymous Coward]

Re: Oh,

Stability, security and performance are more important to Microsoft these days than bolting on features that might mean dropping a flaky product out of the door in what is a $1 billion+ market for them.

Sorry.. sarcasm is hard to detect in a text-only environment.

[Hans 1]

InMemory database ? Sybase has had that for several years now, proven enterprise-worthy with SAP HANA. You know what? Too late, Microsoft.

Why do I say Sybase ? Because it is easy to port applications from MS SQL to Sybase - after all, Sybase are database specialists unlike Microsoft, who have PR/FUD specialists.

No, I have no shares in Sybase, have never worked for Sybase ... I am just saying.

Real men use Oracle.

[Anonymous Coward]

"You know what? Too late, Microsoft."

Right and every one is busy porting their SQL databases to HANA. Oh, wait. They are not.

"Because it is easy to port applications from MS SQL to Sybase - after all, Sybase are database specialists unlike Microsoft, who have PR/FUD specialists."

Just LOL. Sybase is a dying dinosaur. No one uses it for green field sites these days.

"Real men use Oracle."

Only if they need RAC server (and can afford the $100K per socket!). Pretty much everyone else is desperately trying to move to SQL server and has Oracle as disinvest. Oracle still don't even allow for virtualisation (except on Oracle boat anchors) in their licensing agreements ffs!

[JEDIDIAH]

Usual marketing propaganda.

If you've got a job that's so unworthy that you can get no budget for anything then that's just going to be a problem generally. SQL Server isn't exactly free either. Real hardware is going to cost money and so will licenses to go with it. Although if your project is really that small and worthless there are cheaper and free Oracle options.

Although at that point you can probably just manage with mysql or postgres.

[Hans 1]

>Right and every one is busy porting their SQL databases to HANA. Oh, wait. They are not.

Indeed, they are not, guess why ? Why would you not switch to an in-memory database ? Why would you not switch to an in-memory database that uses the same language (TSQL) as your current database ? because you are an idiot! You already are if you run MS SQL Server, so that was easy.

You know, even Postgres and mysql^H^H^H^H^HMariaDb beat SQL server ... and run on an OS that costs a fraction of Windows Server - as we have already demonstrated ad nauseam ...

>Just LOL. Sybase is a dying dinosaur. No one uses it for green field sites these days.

I think quite a "few" SAP customers and finance shops tend to disagree ... ;-)

>Only if they need RAC server (and can afford the $100K per socket!).

Come on, under heavy load Oracle beats a tuned SQL server easily, even untuned on identical hardware. It is unfair, cause Oracle runs on Linux, but so is life! Of course, RAC vs MS SQL server? Not the same league, man ... SQL server replication ? LOL, even Sybase replication server hands that the empty glass of water after the finish line....

DISCLAIMER: No, I do not work for and have never worked for Sybase/SAP/Oracle ... I just happen to be very familiar with a piece of software that runs on a variety of db's, including the above as well as DB2 and a few others ... I see the heavy load stats every morning ...

[Anonymous Coward]

What a retard. Pretty much every FTSE 500 runs SQL server. Except maybe Google and Oracle!

No one installs Sybase anymore except to run legacy platforms like Summit.

SQL Server might not match RAC for Active / Active, but it is someway ahead for replication and Active / Passive Clustering.

The vast majority of new SAP installs go onto SQL Server - which I believe still holds the R3 benchmark record.

And as to performance - you are very much mistaken - Windows Server / SQL Server could match Oracle / Linux a decade ago:

http://scn.sap.com/people/hannes.kuehnemund/blog/2008/06/18/sap-benchmark-performance--linux-vs-windows

And since then has left Oracle / Linux behind in the dust:

http://global.sap.com/solutions/benchmark/sd3tier.epx

http://global.sap.com/solutions/benchmark/sd2tier.epx

[Anonymous Coward]

Windows Server / SQL Server could match Oracle / Linux a decade ago

but unfortunately is still trying to catch up with the current versions

[Hans 1]

With all due respect, did you even read your references ? Because, yeah, I am a bit patronizing sometimes and I tend to rant ... but I am sure you have not even read the links ... and the few drones who upvoted you probably need to return to primary school as well ....

hannes.kuehnemund's blog is from .... 2008 ... 6 years old!

As for SAP benchmarks ... the first link gives DB2 the upper hand (point taken), the second Oracle on Solaris (where is Matt Bryant when you need him).

http://global.sap.com/solutions/benchmark/sd3tier.epx

http://global.sap.com/solutions/benchmark/sd2tier.epx

There is indeed no Sybase, not sure why, but in-memory Sybase beats older MS SQL Server pants down - it has to, it is massively unfair technology-wise and no FUD can change that fact. Now, the interesting thing is how does MS SQL Server in-memory compare to Sybase ... we have not tested that yet.

The funny thing is, look at the date the tests were performed .... Windows/SQL Server has been trying to beat an AIX/DB2 combo since 2005 (currently #2, been beaten last year by another AIX/DB2 combo) ... LOL

Listen, when it comes to performance, real performance, you can forget Windows ... again, MS SQL Server / Windows Datacenter Edition cannot beat AIX 5.3 (!) with DB2 8.22 despite trying for 9 years.

Crawl back into your caves guyz.

[TheVogon]

"hannes.kuehnemund's blog is from .... 2008 ... 6 years old!"

So Windows Server could match Linux for performance 6 years ago as well as a decade ago. Your point is?

"As for SAP benchmarks ... the first link gives DB2 the upper hand (point taken), the second Oracle on Solaris (where is Matt Bryant when you need him)."

But beats Oracle on Linux hands down as was stated.

"Listen, when it comes to performance, real performance, you can forget Windows"

It's a better starting point than Linux these days. Especially for the really high bandwidth / low latency stuff like 40 Gbit Etherrnet and 56GBit Infiniband interconnects, etc. windows has the full capbilities to handle this sort of traffic directly built in - not as bolt on afterthoughts and customisations to the kernel like with Linux.

AIX? Pfft. Again - a dinosaur. No one cares how fast it is once they see the price tag of the hardware...

[Hans 1]

>So Windows Server could match Linux for performance 6 years ago as well as a decade ago. Your point is?

Ok, I did not even read that when I saw the date apparently, you did not either ... ;-)

As much as I hate "benchmarks", because in theory they are the same as in practice and in practice they ain't, even this benchmark gives Suse/Oracle faster than MS SQL Server, pretty close, though.

The second is an old version of MaxDB vs MS SQL Server (where SQL Server wins, tada - you found a benchmark, impressed) and seeing how SAP has improved performance of that DB over the last years, I doubt you would see the same results. You will note that the Database Request time is 6 times better on Linux/MaxDB than Windows/MS SQL Server - so clearly optimization was needed in MaxDB.

Why am I claiming Linux beats Windows all the time ? Because in Windows you have a bunch of unused subsystems and other crap like ui's running, in Linux, you have exactly what you need running. So, there is absolutely no way Windows can outperform Linux - MS have now realized this and you get a headless Windows server now, but, looking at the HD footprint (arguably not very reliable metric), they have only removed ui, not the unused subsystems - I have not tested this, but I am pretty confident. In the other SAP benchmarks, UNIX wins because of the HW, that is why I said on same hw. I could not see UNIX/Windows/Linux performance results with identical hw - might need to export to csv and have a closer look.

Listen, I work on a piece of software that is pretty database intensive and we support a wide array of db flavors and I can tell you, I see the high load tests we run nightly every morning, and they do not look good for MS SQL Server. MaxDB now performs much better, which was not the case some years ago, you are correct ... that is why I am appalled that so many shops run MS SQL Server instead of more capable OS/db combinations ... especially considering the price.

I will stop arguing here because it is in vain, window cleaners have no clue and think they know better - fine, so be it.

As for the other bloke with his 300 quid, lol, you really mean I can choose the sql ? This article says which queries I can choose to prevent you from using in-mem database and you think you can still beat my in-memory Sybase/SLES, seriously ? 300? My rate for two hours work ...

[BlueGreen]

@ Hans 1

> Because in Windows you have a bunch of unused subsystems and other crap like ui's running, in Linux, you have exactly what you need running. So, there is absolutely no way Windows can outperform Linux

You are clearly clueless about how DBs work. I do mean newbie level clueless. I recommend you back out of this discussion before you embarrass yourself further.

> 300? My rate for two hours work ...

Of course it is, dear... barely worth your while, I agree.

[Anonymous Coward]

"everyone else is desperately trying to move to SQL server"

I can confirm that. I, too, have received information that Excel isn't a suitable database.

[Anonymous Coward]

Sybase vs SQL Sevrer really?

With all respect you haven't got a clue what you are talking about. I have been involved with migrations away from Sybase into SQL Server and have noticed from 5 to 10 times better performance, sometimes even better. Are you really a database person? I have never heard of anyone who wanted to migrate to Sybase from SQL Server. I have very extensive queries and results and all evidence to support the migration to SQL Server.

What the new in memory database 2014 features do? They offer even more options when your traditional SQL Server database is running bit slower than it should. So you can implement that part of the database and SQL code in memory to go even faster. I have used Sybase for 6 years exclusively and still have to use it, alongside SQL Server and don't even know where to start with the performance shortcomings I see on a daily basis. It starts from the idiotic Sybase optimiser. And yes using the latest version for Sybase.

By the way check the www.tpc.org website and see which system has the top 10 results for the traditional RDBMS running a brokerage system with the 30-40 tables necessary. Why none else submitted their results for the past 4 years? Simple they are not even close. Not oracle, not db2, never mind Sybase.

[Anonymous Coward]

Re: Sybase vs SQL Sevrer really?

I don't know if you're telling the truth about your experience or not but I have almost the opposite experience having worked with both MS SQL Server and Sybase since before the two split.

I've found ASE performance is usually, but not always, ahead of MS SQL Server. They both have some nice and useful features that the other one lacks but overall I much prefer ASE for its performance and ease of use (plus I'm not tied to Windows).

My experience covers many years for many different companies and in several different countries.

SQL Server certainly has better market share these days but I have worked on migrations from MS SQL Server to Sybase and they've all worked and provided better performance. On the other hand, the thing about migrations is that usually you're migrating to newer and faster hardware and often different software so they're not always good comparisons.

[Anonymous Coward]

Re: Sybase vs SQL Sevrer really?

I've recently worked on a couple of Sybase green field sites. To say that "no-one installs it anymore" is a bit childish as have been a lot of the arguments here.

I would point out that there's SAP HANA and Sybase/SAP also have ASE which has had in memory databases for some years (with no limitations on what SQL you can run).

I suggest that people try the various RDBMSs for themselves or at least read up on them rather than get involved in stupid name calling.

I've been a DBA for a long time and worked with Sybase, Oracle, MS SQL Server, MySQL, Ingres/Postgress, IDMS, DB2 and others. Almost all of them have their strong points.

[Anonymous Coward]

Re: Sybase vs SQL Sevrer really?

"I've recently worked on a couple of Sybase green field sites"

Then you are a lucky man to find them for your rapidly becoming legacy skills with Sybase. I will qualify that to no one sane deploys Sybase in a greenfield site.

Sybase ASE is a dying niche product, and don't seem to have released a major update for the last 8 years!

[Hans 1]

Re: Sybase vs SQL Sevrer really?

> Sybase ASE is a dying niche product, and don't seem to have released a major update for the last 8 years!

They just managed to add in-memory support years before MS ... ok, they did not hike the version number that much ...but did not seem to need to - they are not Mozilla.org.

SAP bought Sybase for SAP Hana, if that does not tell you anything, fine ... they WERE a niche product, they almost died, then John Chen came along and saved their asses, now SAP is pushing them strong ... watch this little baby, I tell ya!

[pan2008]

Re: Sybase vs SQL Sevrer really?

Are you talking about a comparison between SQL Server when it was released in 1994 with the 1994 Sybase or something recent? Must be the 1994 version you last compared.

"I much prefer ASE for its performance and ease of use" where is the ease of use with Sybase, I am losing you here. It doesn't even have a proper SQL Development env I am using something that was hacked together by Sybase. Compare this to tools you get with SQL Server. Unless you prefer using the command prompt and you find this easier.

Why don't you put your money where your mouth is if you feel so confident with Sybase, £300 bet for the winner. I challenge you to beat SQL Server with any bit of SQL you want (has to be reasonably complex) not a join between 2 tables!. We run on same machine, same indexes, same data, I guess you want Linux, I use sql server 2008. You provide the SQL (or have plenty SQL anyway), we need few tables with some million rows each. You devise the SQL tests, but needs to be complex sql.

Contact me at sqlsybase at gmx.com if you would like to win £300.

As of Hana, this is not a proper relational database and have never seen it on a Sybase install. Should I mention tabular then on sql server then? SQL server has in-memory since 2012. Check the 2 billion rows it can query in 1 second white paper. But lets keep this simple RDBMS vs RDBMS (ACID compliant) systems only.

For the people who say Linux or windows or whatever, the Database is a fast as the optimiser is. Awaiting your email...

[Anonymous Coward]

Re: Sybase vs SQL Sevrer really?

We've recently run Sybase v MS SQL Server performance tests and Sybase came out fractionally ahead for fairly simple heavy transaction processing.

I can't share the results because they're client confidential.

I would be happy to take up your bet but I can't see an easy way of ensuring a fair comparison when I imagine we're not very geographically close together. I'm open to suggestions.

As for "Sybase ASE is a dying niche product, and don't seem to have released a major update for the last 8 years!". I'm afraid you're showing your ignorance there! Sybase ASE 15, then 15.5, then 15.7 and now 16. Even within 15.7 we got lots of nice new features with most "patches". Perhaps they should use bigger numbers for people like you? You may not like Sybase but to say that it is dying is manifestly untrue.

[pan2008]

Re: Sybase vs SQL Sevrer really?

First of all I am not the commentator who wrote about the dying niche product, not that I strongly disagree with him. I haven't seen Sybase in any new project except for old legacy apps.

So you based your performance benchmarking on some simple heavy volume transaction insertions? Do you call this a real and comprehensive test? I still find it hard to believe that SQL server was slower on the simple stuff, but ok can accept that it may be 5-10% slower for inserts if I understand your test correctly.

However, Performance testing is executing complex queries, running complicated stored procedures, testing user load from simultaneous connections while inserting/updating data. This is what users do on a daily basis, this is where the database goes slow and separates the men from the boys. You have my email address, so do contact me.

If you set-up your Sybase env and install sql server, I can remote desktop via logmein or similar. I am sure we will find a way if you really want to know the truth. But as I said I have done numerous very comprehensive tests and SQL Server easily beats Sybase. And I see this on a regular basis in my job, I have to use Sybase.

[Herby]

"In memory" database.

Seems typical. For performance upgrade, buy more hardware to make system run. Microsoft has been doing this for years.

I had a W98 laptop that (originally) came with 32MB. Good luck trying to run anything on that small of memory these days!

Microsoft upgrades: Please upgrade your hardware first!

[Anonymous Coward]

Re: "In memory" database.

SQL Server 2014 will run faster than earlier SQL Server versions on the same hardware.

[dogged]

Re: "In memory" database.

Not sure if serious...

[Drew Furgiuele]

One omission from your article worth noting...

Liked the article, but there's one MAJOR reason you'd want to consider making the jump to 2014 even if you recently upgraded to 2012: The Standard Edition of SQL Server has raised the max memory limit from 64 to 128GB; that's a huge win for smaller shops or people who don't want to pony up for Enterprise Edition. Granted, you miss out on pretty much every other new feature Microsoft has put out with 2014 but you could easily grease all your instances with more RAM and get some nice performance hikes just from that alone.