
SQL Server 2014 Standard Edition Sucks - daigoba66
http://www.brentozar.com/archive/2013/07/sql-server-2014-standard-edition-sucks-and-its-all-your-fault
======
jaynate
For years Microsoft-sponsored SQL Server consultancies have been telling us to
use the database to its fullest extent. Use Stored Procs and non ANSI SQL
features, they're fine! Logic in the database? We love that.

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.

~~~
sehrope
I see nothing wrong with using stored procs or non-ANSI features. You just
need to know what you're getting into. The same goes for any database. Being
database agnostic is great but so is actually finishing what you're working on
and having it run efficiently. If DB specific features get you there and
you're willing to accept the terms of being locked in then it's a sound
decision.

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.

[1]:
[http://www.postgresql.org/docs/9.2/static/hstore.html](http://www.postgresql.org/docs/9.2/static/hstore.html)

~~~
eksith
"...so is actually finishing what you're working on and having it run
efficiently."

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.

~~~
sehrope
To clarify by "finished" I meant shipping a working version of a product, not
being finished with all work on the product.

------
MichaelGG
The funny thing is how Microsoft used to make fun of Oracle for being
restrictive on the CPU licensing types. How "hardware improvements are for our
customers' benefit". Now? You pay differently depending on AMD/Intel and type
of chip. Oh hey, just like Oracle. It's hypocritical, but I guess it's also
just business.

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.

~~~
xradionut
You have to be a DBA to properly use SQL Server too.

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?)

~~~
chris_wot
(Tempdb, what's tempdb? Clustered index, what's that and why the hell do I
need one? Escalated locks - what the hell? Isolation modes, why are they
important?!?)

~~~
taspeotis
I'd be happy if the outsourced developers I work with knew what an index was,
let alone whether it's clustered or non-clustered.

It would be refreshing to see seeks instead of scans in the execution plans...

------
forgotAgain
I wonder if those working in corporate IT realize that they're competing with
Microsoft for money.

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.

~~~
incision
_> "I wonder if those working in corporate IT realize that they're competing
with Microsoft for money."_

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.

~~~
corresation
_they aren 't afraid to be blunt and say "Hey, you can get rid of your staff
if you go with this"._

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.

~~~
dacelo
Yes, once you switch to ALL XaaS and ditch your IT staff, you are forever at
the mercy of your existing XaaS vendor. You don't own the software, the vendor
actually has your data somewhere in the cloud, and you have no one who can
even make a credible recommendation on an alternative. They got you by the
balls, and BTW, the XaaS pricing is tripling next month. Muahaha !

~~~
incision
This is all true of existing Enterprise software relationships.

------
vyrotek
My company went through BizSpark 3 years ago. We're now running everything on
Windows Azure. No complaints here. Sure, I'd like SQL Azure to have a few more
features but there haven't been any deal breakers yet. C# is by far my most
favorite programming language and is probably what keeps me coming back to
.NET & Sql Server.

I must admit though, I'm very intrigued by a lot of cool features found in
PostgreSQL. Specifically HStore.

~~~
xradionut
Chances are you are not dealing with banking, insurance or medical data while
running on Azure. After the last several weeks, we had to assure clients, that
none of the data is stored on Azure. Plus with the standard version of SQL
Server or Azure you don't get full auditing or encryption.

~~~
vyrotek
That's correct. I actually used to work for a company which built health
information systems for hospitals so I'm aware of the hurdles there. They were
.NET based too. Hospital network contracts pay very well but they are
absolutely the worst customers.

------
cl8ton
MS is not changing their tack because there is a vibrant big business
community with budgets that depend on MS SQL and it fills the need.

Which Open Source DB does everything that MS Enterprise SQL does and why
aren’t you using that instead?

~~~
BrentOzar
> Which Open Source DB does everything that MS Enterprise SQL does and why
> aren’t you using that instead?

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.

~~~
xradionut
We were skeptical of Azure before NSA revelations, but now; "Hell No!".

Besides that, Microsoft has pretty well pissed off all but the most entrenched
developers.

~~~
recursive
It seems to me that the group of "most entrenched developers" is still pretty
big. In real life, it's the most common kind I see.

------
CurtMonash
64 GB of RAM is 100,000 times more than what Microsoft used to think people
needed.

: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.

------
taude
We figured out we weren't using most of SQL Server's features and didn't want
the mental overhead of MSFT licensing. We switched to Postgresql and haven't
looked back.

~~~
BrentOzar
How big was the application (like how many developers were involved in the
migration, data size, etc)?

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.

~~~
taude
It was several smaller apps written with most logic in the app (Hibernate) and
had very little T-SQL/stored procs. We also weren't using any of the add-ons
like SQL reporting, etc. The big commercial DBs have the advantages when you
start using their reporting services, BI/OLAP stuff...and likely when you have
several different groups as stakeholders in the process...

------
teilo
I just took my first plunge into the caustic waters of SQL Server, being
forced there because my company is deploying a vendor-supplied shipping system
that only runs on it. Since the data set would be growing beyond 5GB, SQL
Server Express was not an option. Coming from a Postgres world, Linux, Java
world, the whole subject makes me sick.

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.

~~~
WayneDB
SQL Server 2012 Express allows up to 10GB databases.

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...](http://www.mssqltips.com/sqlservertip/2942/understanding-the-sql-
server-2012-licensing-model/)

"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.

~~~
teilo
The minimum cores you can license on MSSQL, whether on bare metal, or a VM, is
4. Wherever you run it, you must license all cores available to the OS. Had I
chosen to run on bare metal, I would be forced to license 12 cores (6-core
Xeon CPU x 2). This app requires SQL Server 2008 R2, so the 4GB limit applies.
But I can't buy 2008 R2 anymore directly. I have to license 2012, and use my
downgrade rights.

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.

~~~
WayneDB
You said "...because it's not a public website, but a private web app."

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.

~~~
teilo
So, your argument amounts to this: Ignore Microsoft's licensing requirements,
be a pirate, and just lie through your teeth.

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.

~~~
WayneDB
I only said one third of that. I also said that I don't think you're as
restricted with intranet web apps as you are with public web apps, but I could
be wrong...

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?

~~~
teilo
I'm aware people lie all the time. I'm aware that sometimes they get caught.
I'm aware that when you owe millions of dollars to a bank, the auditors
actually check this stuff.

"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.

~~~
WayneDB
Ummm, okay whatever you say...

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.

~~~
teilo
I bow to your manifestly superior entrepreneurial prowess. Obviously, I am too
stupid to know how lame Macs are. That explains why my company has maintained
a paltry year-to-year growth rate of not less than 50% for the last 15 years.

Oh, and for the record: "Am I bovvered? Look at my face. Am I bovvered
though?"

[http://www.youtube.com/watch?v=K7lcm7Vp_p0](http://www.youtube.com/watch?v=K7lcm7Vp_p0)

~~~
WayneDB
Please, excuse me if I don't believe you in the slightest. I'm sure though, if
you tried really hard, you could even attribute your imaginary profits to your
use of Macs. I'd love to see some of your hipster logic in detail.

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 :)

~~~
teilo
Your a funny guy. You ready to call me Hitler, yet?

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.

~~~
WayneDB
I certainly don't need to know you or even have a "vendetta" against Apple to
have a good laugh at someone complaining about SQL Server pricing when they've
happily paid Apple for the privilege of running OS X.

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 :)

------
HalBerenson
I'm pretty sure I wrote about the history of the Enterprise vs. Standard
decision making on my blog ([http://hal2020.com](http://hal2020.com)) but I
can't find the post right now. I'm one of the people responsible for the
original philosophy, and I don't think it's changed much. I'll go back and
look for it again.

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.

------
akurilin
Brent, to which db flavor do you recommend people migrate? Thoughts on
Postgres? Btw, loved your vlog post on scaling SO's db layer.

~~~
BrentOzar
> Brent, to which db flavor do you recommend people migrate? Thoughts on
> Postgres?

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.

~~~
statictype
I wonder if that was sarcasm :)

If you spend too much time on HN, you'll end porting your RDBMS to Mongo DB or
Voldemort.

~~~
akurilin
Hipster News. I joke I joke, right tool for the right job, right?

------
epochwolf
This won't change because large companies don't like open source.

~~~
wmf
At these prices it seems like you could take Postgres, wrap it in a support
contract, and call it EnterpriSQL and still charge less than MS.

~~~
daigoba66
Someone beat you to it:
[http://www.enterprisedb.com/](http://www.enterprisedb.com/)

~~~
MichaelGG
Actually, most of their prices are "Call us!"[1]

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...](http://www.enterprisedb.com/products-services-
training/subscriptions)

~~~
piggity
SQL Server Standard is $2K per core - with > 4 cores per socket, things flip
around a bit.

I'm not a SQL licensing guru; so perhaps I'm confused as well...

~~~
MichaelGG
So let's say 4 cores @ $2L, $8K. Then you pay like 35% a year for software
assurance; so you'd end up with $2800 a year.

No one buys MS servers products at the flat retail price. They work out plenty
of long-term strategies to help you pay.

------
programminggeek
I'm sorry, but if you have to read a feature grid to figure out what a product
does, you've already lost.

Also, isn't this when you look at Postgres or MySQL and go... licensing cost,
what licensing cost?

~~~
samgreene
I don't think this is a useful mindset. Grids are very handy comparison tools.
Also, licensing costs are only part of the overall cost of running a service.
'Serious businesses' will not run on a piece of software that is not supported
by either a vendor or their own staff. Not everyone is comfortable fixing bugs
in their DB platform, or relying on the community to do it.

------
yuhong
I wonder which edition StackExchange use?

~~~
BrentOzar
> I wonder which edition StackExchange use?

Enterprise for the memory and the ability to do online reindexing. They were
in the BizSpark program, so they basically got free licensing.

~~~
yuhong
And they are on Software Assurance, right?

~~~
BrentOzar
Yes, when you exit BizSpark, you can just start paying maintenance on the
servers you were using during the program.

------
ivanbrussik
saved this post for just another reason why open source is going to take over
the world

------
dschiptsov
2014 Standard Edition only?))

------
corresation
I assume that the linked blog intended to link to
[http://msdn.microsoft.com/en-
us/library/cc645993(v=sql.120)....](http://msdn.microsoft.com/en-
us/library/cc645993\(v=sql.120\).aspx)

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).

~~~
adamconroy
All tables in sqlserver will be memory resident if there is available ram. But
it happens dynamically, or is non-deterministic if you like. I assume the in
memory feature allows you to force a table into ram and force it to stay
there.

~~~
BrentOzar
> All tables in sqlserver will be memory resident if there is available ram.

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.

------
trackztar
Didn't read. Used the word Seriously in the first paragraph.

Grow up noobs. Holy fuck!

~~~
BrentOzar
> Used the word Seriously in the first paragraph.

Actually, that was the second paragraph.

~~~
chris_wot
Don't feed the trolls.

