SQL Server 2014 Standard Edition Sucks
brentozar.com
brentozar.com
That's what ISVs and Enterprises are being told to do and that's exactly what they've done, at least the ones who couldn't see Microsoft's business angle. Now many are left to choose to either accept Microsoft's ever-increasing licensing costs or a high cost to switch.
I agree with @BrentOzar, time to find other options.
For our product we use Postgres as the app's database and happen to use some Postgres specific features like stored procs and hstore[1]. The latter in particular is not ANSI at all. There is no equivalent at all in other databases and migrating usage of it to another DB would be a real pain. I know we're tied to Postgres and we're ok with that as it's a joy to use and let's us spend our time elsewhere.
You use database specific features because they're useful, not because you're forced to. Of course I'll concede the point that it's a bit apples and oranges to compare being "stuck" on Posgtres vs a commercial closed source stack.
A "finished" product is usually a dead one and efficiency is relative. You've seen that incremental improvements to the entire stack can have far greater impact than fiddling with just the storage end alone after all.
A product never actually stops evolving if it's going to stay competitive and make money. But I'd say staying with Postgres is one of the best decisions you've made. Besides being a joy, as you say, you can be fairly confident that it won't suddenly become broken, become proprietary and best of all, become an order of magnitude more expensive for the same capability.
At any rate, like this post says, whatcha going to do? The ease of use of SQL Server is fantastic. As much as I would like to use Postgres (despite the HA story looking very confusing, and lack of basic things like materialized views), the tooling is lightyears behind Microsoft's. The fact that I'd truly need to become a DBA to properly use Postgres (oh great, an ini file with poorly documented settings!), whereas I can fumble my way through SQL Server... that's worth a lot.
Yes you can stumble your way through wizards and SSMS, but you will get tripped up eventually if you don't spend some serious time hitting the books and blogs. (Recovery model, what's a recovery model? Why's my disk space gone?)
We're both right depending on the value of DBA. I don't think the argument can be made that SQL Server will require vastly less effort to figure out for the majority of cases (and edge cases have people explaining things assuming you're not an expert).
It would be refreshing to see seeks instead of scans in the execution plans...
Most corporations see IT as an expense center. It's not a place where the business make money. It's simply a place where they spend it. You can argue the validity of that idea but whether it's right or wrong doesn't matter. It's the way most businesses think.
Businesses, of course, try to limit expenses. They especially try to limit any increase in expenses. So basically there is a certain sized pile of money for IT to work with. If the costs of Microsoft infrastructure goes up, the difference is made up by cutting another part of the pile. The part of the pile that can be most easily managed is salaries.
Generally no, but I expect many are quickly realizing it.
Microsoft in particular has been very open about trying to sell things like Office 365 and Azure to Enterprises. They aren't afraid to be blunt and say "Hey, you can get rid of your staff if you go with this".
It's an odd relationship.
In my experience, many in corporate IT are perfectly happy to be simple facilitators - shoppers basically.
I believe the perception is "It won't be me", that being increasingly beholden to a vendor might prevent the creation of new positions or filling vacancies but will never eliminate their own positions.
The entire industry of internal IT support has hard times ahead. Anecdotally, I see XaaS being adopted surprisingly quickly. A few big VARs I've talked to have noticed this and have been realigning themselves to sell managed services instead of stopping at planning and implementation as they have in the past.
During the release of, I think, Windows 2008, Microsoft put out an ad campaign that showed the IT staff doing the congo and other non-work things. It was a fun, upbeat message about how it made things so much easier. Only the real, unavoidable message was to HR and the executive -- give us some cash and you can start sending out the layoff notices.
I'm not judging Microsoft for that -- they've forever boasted that if you go with Microsoft stuff you can pay your employees less -- and efficiency is good for everyone. It was just such a bizarre ad, and seemed to be like one of those dark side Skittles ads, but minus the awareness of what it really was.
I must admit though, I'm very intrigued by a lot of cool features found in PostgreSQL. Specifically HStore.
Which Open Source DB does everything that MS Enterprise SQL does and why aren’t you using that instead?
They shouldn't fear a competitor that does everything they do. They should fear a bunch competitors each doing a set of features a given customer needs.
SQL Server is Microsoft's best software product, but why would I even bother with it since both MySQL and PostgreSQL do everything I need from an RDBMS, for a tiny fraction of the TCO and with comparable if not better performance and much better platform support? And why would I even consider it when non-relational datastores are a much better fit for most of my data? It makes sense if you are into Windows, but makes no sense whatsoever if you are not.
I used to think the replacement wouldn't have to do everyone MSSQL does - after all, nobody uses all of the features. But getting a core subset often isn't enough either - for example, Windows Azure SQL Database supports a core subset of features and datatypes, but I still constantly hear people say it's not enough to migrate their apps.
Besides that, Microsoft has pretty well pissed off all but the most entrenched developers.
This does suck for small/mid sized businesses though. :/
:D
Seriously, Oracle's biggest point of losing customers is when it's time to upgrade from Standard Edition to Enterprise Edition ... or else pick an alternative. I imagine something similar is true for Microsoft SQL Server.
How long did the migration take? Was the business okay with a feature freeze during that time, or did you take advantage of the switch to rewrite it too?
Did you have multiple connected systems, like ETL processes that also hit the database for other reporting systems?
Always curious about these kinds of issues because they seem to be what's holding businesses back.
We also switched the DB servers to over to linux and got a huge performance boost from that.
We did rewrite some stuff, but that was mostly to take advantage of postgres features like array types (instead of a article tags table, you'd have an tags array) which we used to speed up some applications. One we sped up by a factor of 10, just by using array types and offloading json generation to postgres: select array_to_json(array_agg(row_to_json(t))) from ( some query ) t
I was disgusted to discover that my 200-strong Mac shop would have to spend $7,000 on SQL Server. I was even more disgusted when I discovered that Microsoft no longer lets me run it on the server I purchased, a dual 6-core machine, because now EVERY core is licensed individually, and you are FORCED to license every core in the machine. You can't just license some of them. That forced to run it in a VM, which is just asinine. And THAT means that I also had to purchase an additional Windows Server license to run a SEPARATE VM for IIS/ASP.NET.
And THEN (and this is the part that offends me most of all), I have to purchase a CAL for every damn machine that will be using the shipping system, because it's not a public website, but a private web app.
Also, you should only need CALs if your private web app is using Windows Authentication to make each database request on a per-user basis.
From http://www.mssqltips.com/sqlservertip/2942/understanding-the...
"you have two choices: purchase per core licenses at $1,793 or purchase a server license at $898 and client access licenses at $209 per client."
So, if everyone is going through the web app and the web app is not using Windows Auth (you certainly don't sound like you need to use that) - You should be able to get SQL Server for ~ $1107.
You are wrong on the Windows Authentication requirement. This has nothing to do with anything.
For MSSQL, you must license the database per core if you are using it in a public web application, because you have an arbitrary number of users. And you must license all cores in the machine. The VM is the only way to license only some cores, namely, as many cores as are in your VM.
If you are using MSSQL in a private web application, you may choose CALs. However, if you do so, it doesn't matter how users authenticate. Each user or device needs a license. Microsoft is very clear about this. User count is just that: the number of users using the database, either directly, or through a web application which does everything through a single set of credentials. It's not system accounts. It's users or devices.
The same applies for Windows Server licenses. It doesn't matter how the user authenticates. If they are using a web-app hosted on a Windows Server, and that web-app is not publicly accessible (a login page does not count), then you need a CAL for each user or device.
So, you do not have to license it per core. You can buy the $898 standard version and a few CALs - one for your web app and the rest for db admins.
Furthermore - even if there is some wording that says "if 100 people are hitting your private web app, you have to buy 100 CALS" - just ignore it like everybody else does.
No, this is not what "everybody else" does, especially those who must answer to shareholders, compliance personnel, and a management team that actually cares about staying within the bounds of the law, and not paying thousands of dollars in civil penalties should we be found in violation of a licensing agreement.
This is why we develop everything we can on an open source application stack. But we can't write everything from scratch. We aren't going to spend $100K+ developing an entire enterprise shipping system from scratch. That means we must purchase proprietary solutions that will cost us much less and have a greater ROI. That also means licensing compliance.
Anyway - you can lie if you want to and I certainly won't judge you - but I didn't say you should lie or be a pirate. I said ignore the license. Big difference. (From your original post, it sounded to me like you probably don't have shareholders. Do you?)
Are you aware that vast numbers of small, medium and even larger size businesses are running SQL Server without the proper licenses? Are you also aware that Microsoft knowingly allows this to happen with a wink and a nod? Just like Windows and Office...until XP/2003 when they turned to activation. They didn't do that for SQL Server or many of their other products as far as I can remember. Could happen, but we'll see...
So yeah, advising you to do what millions of other business do too - I have no problem with that. (I also have no problem bribing the locals if that's the normal course of business. Don't think of me as immoral - I'm a realist. Big businesses squeeze everybody in one way or another, so if you can get away with it - it's great advice. The risk goes up the larger your company gets, obviously...)
Also, SQL Server 2012 is 100% backwards compatible with 2008 R2. So Express 2012 would definitely work (Microsoft is legendary for their backwards compatibility. Just sayin'.)
What kind of business are you running 200 Macs for anyway?
"I didn't say you should lie or be a pirate. I said ignore the license."
And with that you lose the argument, and all credibility.
Enjoy the lame Mac-based "business" infrastructure that you built. Maybe if you'd gone with Windows to begin with, like every other business on the planet - you'd have saved enough money so you wouldn't be complaining about Microsoft's server licensing costs right now.
Oh, and for the record: "Am I bovvered? Look at my face. Am I bovvered though?"
Anyway so, say you're making good money and the only product that can apparently fill your needs properly requires SQL Server....and yet you're still complaining? With all that money you have? One would think you'd be happy to even have found a product that does exactly what your business needs.
Did you wonder though why there are no products for you that run on OS X? (It's a real mind-boggler for you, I'm sure.)
I'm still laughing at the fact that you've (allegedly) spent well over $100K on overpriced Apple hardware and yet you have the audacity to complain about spending a fraction of that on some software that you actually need. Really...thanks for the entertainment :)
I never said our infrastructure was Mac-based. Our user machines are Macs. Our infrastructure is almost entirely Linux/Java/Postgres. We are in the printing and graphics arts business. Hey, imagine that, a Mac-dominated field - but Macs are so lame that no one could possibly have a good reason for using them, right?
There's a reason we don't use Mac servers (aside from a file server). They suck. Apple has sucked at servers ever since they abandoned the enterprise when they cancelled XServe (which we never used), and re-focused their server product for small business and home use.
We also run Windows terminal servers, press controllers and RIPs, legacy shipping systems, etc. Our CAD team uses Windows. I've been in this industry for 20 years, and have worked with pretty much everything out there in common use.
As for attributing our quite real profits to the use of Macs - don't be a moron. Our profits are the result of a world-class management team with whom I am privileged to work.
You are excellent at stereotyping, and obviously have a vendetta against Apple, and by extension, anyone using Apple products. I'm sorry for you. We are not mind-numbed robots. We have reasons for the business decisions that we make. And we, despite your consternation, have been just as successful as I have asserted.
And hipster? Wow. You don't know me in the least.
I'm going to let you have just one more "last word" here though because that seems to be important to you. Good night, my fellow comedian :)
and then the BSA comes calling.... it's not worth the risk.
Basically you have three dynamics going on. The reality check of course is that the competition is Oracle and IBM DB2, and to a lesser extent open source databases, and various analytics products. Check out Oracle's price list and SQL Server Enterprise remains inexpensive. And Microsoft has introduced cheaper options to keep "free" open source options somewhat at bay, though the truth is that without multiplatform support there is nothing they can do to really capture that segment of the market.
Standard Edition exists because I couldn't convince my then boss that we should bifurcate it into a couple of sensible products, one slightly lower in capability and one slightly higher. The slightly higher one would have been a "Small Business Enterprise" edition that included many of the features of Enterprise but somehow retained differentiation from full Enterprise and would have been dramatically less expensive. I had a differentiation, but I don't recall what it was. The reason the bifurcation was rejected was that Standard was the edition that matched earlier versions and we didn't want to piss off customers by forcing them into a more expensive or less functional edition. And we didn't want to complicate the world with yet another two editions. So the status quo was maintained. BTW, this is a late 90s discussion.
The next dynamic is that there are a lot of features which cause a crapload to engineer but don't increase product volumes substantially. This is the primary driver of what becomes a candidate for Enterprise rather than Standard. When you are investing $10s of millions in a particular feature's engineering then you want some way to get a return on that investment. It really is that simple. Almost.
There is (or was) a re-analysis each version of what goes into each edition. My philosophy was that you introduce new enterprise features in the Enterprise Edition, then examine moving them into Standard Edition in subsequent releases. So there is a constant stream of new high-end features flowing into Enterprise, then as they become part of the mainstream thinking you push them (or appropriate subsets) into Standard. But that philosophy was never adopted and so the effort seems far more haphazard than I'd wanted it to be. Customer and competitive pressure will result in capabilities being pushed into Standard, but it doesn't seem to happen in a rational way.
Max memory size and high-availability features were the original differentiators when Enterprise Edition was introduced as a mid-life kicker for SQL Server 6.5. In the case of memory it was an actual technology differentiator back in the mid-90s on 32-bit machines. That it has survived through the 64-bit transition is shocking. But the reality check is likely that very few servers actually have more than 64GB,despite today's hardware prices, and thus Microsoft sees it as an acceptable differentiator. High Availability should remain a differentiator, though a simple subset does need to be in Standard. That the current subset is actually deprecated is, ummm, looney.
Customer demand for capabilities in editions other than Enterprise, or competitor moves, will lead to Microsoft changing the balance between Standard and Enterprise. But it isn't a few sophisticated DBAs/developers/etc. calling for the change. Or a niche or flash-in-the-plan competitor. It is an actual shift in market dynamics.
I'm not the right guy to ask on that one - I just don't have enough experience with alternative platforms. You're in the right forum though - as long as you follow the news on HN, you'll do a good job of choosing the right data storage platform for your needs.
If you spend too much time on HN, you'll end porting your RDBMS to Mongo DB or Voldemort.
Then by all means, add it in the comments and I'd be glad to point to it. I'm just not qualified to make that recommendation myself. My experience with other platforms amounts to importing data into MySQL for WordPress, heh.
At my company, the team using Java+PostgreSQL is twice the size (~120 people) of the team using C#/MSSQL (~60), and the only ones really "stuck" right now re: tech are the ERP folks, because that has such a huge switching cost in the change management/training side of things, not to mention the whole "what do I do with all my legacy data when it doesn't have a natural fit in my new ERP?" problem.
They don't seem to mind open source as such, and will use open source without support contracts for tools that aren't key infrastructure (or for libraries for internally-developed software), and probably wouldn't mind open source with a support contract for key infrastructure (but for a lot of things, proprietary s/w vendors are just better at selling support than the people selling support for open source software.)
Looks to be at least $4000/socket/year. So, more money than SQL Server Standard, less than SQL Server Enterprise.
1: http://www.enterprisedb.com/products-services-training/subsc...
I'm not a SQL licensing guru; so perhaps I'm confused as well...
No one buys MS servers products at the flat retail price. They work out plenty of long-term strategies to help you pay.
Government dislikes open source (you know, communists).
Also, isn't this when you look at Postgres or MySQL and go... licensing cost, what licensing cost?
Enterprise for the memory and the ability to do online reindexing. They were in the BizSpark program, so they basically got free licensing.
SQL Server has been getting much more expensive because their current userbase is captive (meaning the cost, complexity and risk of migrating to another database system is enormous because of a heavy integration with SQL Server specific features). I don't imagine a large number of new systems are being built around SQL Server, apart from those at shops that are already captive.
It is an excellent database, but I do get a chuckle that by far the greatest benefit being pushed for SQL Server 2014 is in memory tables (which is something that SQL had -- at least for temporary tables -- back in the 6.5/7.0 era, but then had removed). While it is hardly identical, an approach we did on one team is to have SQL Server take 64GB (note that it is per instance, and most server deploys see many instances on a single server, so that isn't quite as prohibitive as it might sound) and then have an enormous RAMDISK on which tempdb would be created. Made use of the RAM, and saved enormous amounts of IO (tempdb is the weak link of almost all SQL Server platforms, as everything hits it, especially if you make use of snapshot isolation / row versioning).
Great catch - fixed, thanks.
> greatest benefit being pushed for SQL Server 2014 is in memory tables (which is something that SQL had back in the 6.5/7.0 era, but then had removed)
Sorta kinda - back then, we had DBCC PINTABLE, and it would cache the data, but it would still require that the transaction logs and data pages be written to disk. Now with Hekaton, you can specify that a table never hits disk, ever. (Don't get me wrong, I don't think people are going to adopt that particular feature due to other limitations around datatypes and supported syntax.)
It made tremendous sense because that's often an area of enormous churn (I saw a ServerFault post or something where someone did this and saw 30 iops to it, wondering why it didn't improve their system. That is nothing. One product I worked on saw literally hundreds of thousands of IOPS, and everything that sped tempdb sped the world).
If so, I can't understand why. Hash Joins? Often uses tempdb. Snapshot Isolation (otherwise known as multi version consistency by every othe major database vendor)? Uses tempdb. Reindexing? Uses tempdb. Temp tables, cursors or user objects used across your databases? Uses tempdb.
I can't for the life of me understand why Microsoft built in this bottleneck into their database server!
I'd love to know why Microsoft do so many things in a shared resource. In Oracle you can setup multiple temporary tablespaces, curious to see what Postgres does.
Disclaimer: I work at Microsoft in "the SQL org" but I'm just a peon so what do I know?
That explains the pricing of Enterprise, but not the crippled memory (64GB) or the lack of decent features in Standard Edition. Standard doesn't compete with Oracle - or if it did, it would get laughed out of town for a 64GB memory limit.
Standard used to be a gateway drug that would get people hooked on good-enough performance and easy-enough management, but these days, crippled with $500 worth of memory, I don't think that reputation's going to hold out.
Beyond that, if you need something at that scale, often SQL isn't necessarily the right choice.
It's $500. When you consider that bringing in a performance tuning consultant can easily cost thousands of dollars per day, $500 worth of memory isn't much at all.
> for that matter a db install that would need 64GB of memory is probably not something you would call short of "Enterprise" ...
Remember that database servers use memory for at least 4 things: caching data, workspace for running queries, workspace for TempDB, and caching execution plans. If you run DMV queries against sys.dm_os_buffer_descriptors, you might be surprised at how little of your memory is being used to cache data. Even a 50GB database can get to a point where it's having to hit the disk in order to satisfy queries.
This is the age of "big data", as much as I hate to use that term. It's the age of 256GB USB thumb drives, laptops with 32GB of memory, and storing files in the database server. 64GB isn't large for databases anymore - in fact, it's a fairly unusual week when I'm dealing with a database that small.
Yes I have seen many extremely poorly designed schemas that did take up huge amounts of memory, but that is easily corrected before launch. Don't store everything as a string, that's one way. But there are more reasons such a schema needs to be fixed, other than the $ cost of memory.
Plus, remember that one server can be used for multiple databases. In SQL Server, it's fairly common to see a single server housing the accounting software, the payroll software, the email auditing back end, VMware Virtual Center's databases, etc.
Oh, and I have seen small businesses running SQL Standard with databases exceeding 500GB and individual tables with over 1.5 billion rows -- and the tables were designed efficiently! They couldn't afford Enterprise because of the tight profit margin nature of their line of work. What I'm saying is, don't discount the data needs of small business.
Even smaller companies in other fields might want to store tons of rows. User action data, for instance. Living in the past and insisting 64GB of MEMORY is somehow huge is just being silly.
[1]: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=...
To license SQL Server Standard on that inexpensive device would cost $28,640, and would, as the blog post mentions, limit you to 1/3rd of that memory per instance.
Databases live on memory, and 64GB just isn't a lot these days (nor is it "Enterprise" when it is vastly exceeded by a very small workgroup server). Their point is absolutely valid, and it is very strange that while memory capacities have exploded, the memory limit is the same that it was with SQL Server 2008 R2 (prior editions didn't handicap memory like this).
Where does mysql stand in all this?
Thanks.
This was 2 1/2 years ago mind you, but I wouldn't mind the extra cores now.
It's another way of saying that yeah, that's old-world pricing.
(1 - I remember when friends told me they were real-time tracking all the telephone calling cards in a moderate sized country, with a Sun and 1G of memory.)
While you're in it.
Then you leave it and start to try to scale out that Windows/.NET/SQL Server/App Fabric deploy you've built, and the expenses start to become very real.
It still takes us weeks to get a hotfix for something yet if they think we owe them something, it's instant audit.
It's bloody depressing really: products are going to shit, prices rising, support declining and we're treated like criminals.
That's where you BizSpark customers are going to be the moment it expires. You have been warned.
Quite frankly, i'm calling BS.
HyperV is years too late. We've had VMware since 1998 and Xen, KVM etc for years as well.
PowerShell - Shit crock from end to end. It's a rotten mess of an over-complicated, inconsistent environment that barely works and performs abysmally at the best of times. They can't even get the story straight on dates. Half of it is UTC and half local time and when you mix, boom!
Desired State Config - We had this 20 years ago on Sun machines, plus it doesn't work very well and is not holistic.
VS2012 - Yeah a little better but still crashes 5 times a day with HRESULT errors and throws your workflow out of the window.
Exchange - "when deployed correctly". Enough said.
What! We get fuck all support. 30 support credits a year which we use up in a month and have to wait 6 months plus for a solution in most cases!
Have you ever tried to decipher microsoft licensing? Probably not - it's a rats nest that means you're always guilty of something.
We can't move to Azure - we have financial, insurance and healthcare clients. None of them want Azure.
I think you're looking through some rose-tinted glasses there.
"Simple" scenarios like maintaining a warm replicated data center becomes a ridiculous exercise of license guessing, where every Microsoft rep tells you something different. Licensing newer instances of Sharepoint is simply a riot.
I'm not saying there aren't advantages, but it's nice as platform and system architects to plan out hardware and software and be done with it, and not get distracted for months discussing exactly which stack of licenses you need from Microsoft.
Or you could just ignore it and hope they don't come knocking. BizSpark is actually a great example where Microsoft encourages that -- the graduation benefits are in many ways incredibly vague (not to mention that the program duration and benefits are changing constantly). Right now when you graduate you get-
up to 4 Windows Servers (Standard Edition) and 2 SQL Servers (Standard Edition)
What does that mean? Per user/device copies of SQL Server, because that would be completely useless to any company serving the internet in any way. Two core copies, because again that's laughably anemic. What does it mean?
Yet almost no one actually talks about what it means because who cares, right? Until the day that the BSA comes knocking because a disgruntled former employee left a tip.
As a simple example: If I understand correctly, BizSpark lets you install a couple of copies of Office and use it for regular word processing tasks within your startup. However, you cannot install the BizSpark Windows 8 desktop license -- those are only for testing and development. I think. There's no indication of any restrictions on the license key download page.
Personally, it's the license compliance overhead more than the fees that drives me nuts about Microsoft. They make it hard to give them money.
We have our platform going through testing against Postgres and SQL Server at the same time thanks to the use of NHibernate. We have already done a successful trial migration which moved an entire vertical subsystem over.
There are a few issues to iron out but we can switch out.
We're not paying for SQL 2014 having been totally fucked over for SQL 2012 licenses due to the CPU to Core license change and our hefty DB cluster has lots of cores.
Also we use an ORM (NHibernate) which abstracts the entire query and schema away from us. We load/perf test that and get on with life. If there are any blockers, it's 99.9% architectural or loading related which we cover with test cases.
For us, the database is the hole we put our shit in when we don't want it in memory any more. Nothing more.
NHibernate, for example, can make it extremely easy to generate extremely poorly-performing queries. It often takes much more care and effort to have it generate mediocre queries than it takes to write good queries and any binding code by hand.
The "abstracts the entire query and schema away from us" and "database is the hole we put our shit in when we don't want it in memory any more" attitudes don't help reinforce the idea that you guys know how to use relational databases properly.
When teams go out of their way to remain as ignorant as possible about relational databases, while also using abstractions that are often inefficient, they shouldn't be surprised if their hardware needs (and their licensing costs, in some cases) balloon due to this inefficiency.
We use Nhibernate profiler to check our SQL output and all of our queries and make sure we're not doing anything stupid.
We know how to use relational databases, but it's expensive and hard representing our problem domain with them so an OO system is better.
We optimise later by switching the engine out to something cheaper. At least we CAN do this with an ORM abstraction without too much pain.
After all, premature optimisation is the root of all evil isn't it?
Why is each page hit running 10-20 queries?
I had jobs run for a few hours on Dev only to take weeks (if I would have let them) on production, which was in ever aspect a beefier machine.
[1] http://sqlserverrider.wordpress.com/2012/12/31/hekaton-recap...
Same feature, just a different benefit. Hekaton's tables are pinned to memory, use a different storage structure, can have their T-SQL statements compiled to native code, and avoid locking.
Right, but Hekaton introduces the option of never requiring your tables to hit the disk if you don't want them to. Think data warehouse staging tables, web session state, or data marts that are easily recreated from source data.
However the issue I'm talking about is primarily churn -- the writing to disk that is often the weak link in larger data systems.
Many completely banal queries generate potentially enormous loads on the tempdb, without the user ever knowing otherwise. And if you're using temporary working tables for large-scale processes (this is common in financial data where based upon the requested data you need to build up from the base data, climbing the mountain until you yield the final rendered resultset. In between there may be hundreds of GBs of churn to tempdb).
And then there's just generally ephemeral data that never, ever needs to live through a server restart, and that you never want fighting for the probably very limited IO.
Grow up noobs. Holy fuck!
Actually, that was the second paragraph.