Choosing Between SQL Server 2012 & SQL Server 2008

Why Use SQL Server 2012 instead of SQL Server 2008 R2?

  • What are typical bases for making the decision?
  • Which apply to this decision?
  • When would we not choose 2012?

Let’s dig in. As all of you know, SQL Server 2012 has been released for general use for a while now. In fact, SP1 and SP2 have already been released.

Now that it’s a proven product, most new customers will probably want to have it. But why? Why not use an older, even more proven product? It’s probably cheaper. This is what I want to investigate with you.

Here are three reasons to buy a new version of something:

  1. You gain more benefits for the same costs.
  2. The new version costs less (this seldom happens).
  3. The new version has additional benefits worth the additional costs.

These seem rather straight-forward so I decided to run a cost/benefit comparison of 2012 vs 2008 R2 aptly titled:

Cost/Benefit Comparison of SQL Server 2012 vs SQL Server 2008 R2 

First let’s compare costs. Actually in its wisdom, Microsoft muddied the waters for such a comparison by changing the basis for computing the cost.

SQL 2008 R2 is based on the number of sockets that are in the host server. (There are some exceptions involving non-typical versions few of us will want to use, so I’m avoiding discussing them. I do so try to avoid unpleasant discussions.  SQL is not unpleasant, but discussing versions such as BI and Web in this context just makes it harder for me to stay on topic, err… give you the info on what you want. I love to digress. It makes me seem smarter…)

SQL 2012 is based on the number of cores in the CPUs. By craftily hiding the details, I can summarize the two versions’ costs as:

SQL Server 2008 R2

  • Standard = $7,499 to $29,996
  • Enterprise = $28,749 to $229,992 depending on sockets. (From 1 to 8 sockets, but I’ve never seen that many sockets used for one server.  Normally at this level, customers choose to use the data center version, but I’m digressing again so let’s stay on the subject.)

SQL Server 2012

  • Standard = $7,171 to $28,688
  • Enterprise = $13,748 to $137,480

So there’s really not much difference in costs.  At, we typically only increase the monthly rate by about $20/month. Not much.

So the costs are not really different.

Returning to the basis’s we mentioned above, we need to ask what do we get for the slightly higher costs?

OK, I’ll ask. What do we get for the slightly higher costs?

Benefits of SQL Server 2012 

1.) Speed—MS says “Much Faster.” Due primarily to in-memory processing. I can’t say how much yet – I’m still testing this. I should know soon.

2.) Current Version.  Oh, now we have to bring in an awkward phrase—Software Life Cycle. MS will only support a version for a certain period. Then it deprecates the product, which means no more new features, later no more non-security bug fixes (Oh, I should use the phrase “features additions.”  After all, this is Microsoft we’re talking about.) Ultimately no more security fixes. Which means you can run it until the hardware doesn’t support it any more. Of course if problems develop, you’ll need an upgrade on new equipment really, really fast, and normally at 6:00 pm on a Friday or 6:00 am on a Sunday.

SQL Server 2008 R2 is on that long slope.  In October (not that far from now), R2 will only get standard support if it has at least SP1 installed. If you call and this SP isn’t applied, you might find out you have to do an upgrade first. Usually that doesn’t take long, as long as everything outside of SQL Server is compatible with SP1. If not, this could get really messy, really fast. You can expect further deprecation, further along.

Aging out is the history of life.

3.) New Benefits: Many people believe AlwaysOn is the best new feature of 2012. Always on is like mirroring on steroids. In fact, mirroring is “deprecated” in 2012. Nasty word that. Things do age out; I think I just mentioned that. Before 2012, the mirror copy of a mirrored database could not be read. It just existed. You almost had to rely on System Manager to prove it even existed. If your system required more than one database to function, then you might find out you were having to access two different databases in two different servers to do your processing. Failovers were by individual databases. So even if you created more than one mirror, if it failed over and the related mirror didn’t failover, you might be offline while you manually failed over the second mirror. In this case, Heaven help you if you hadn’t setup your logins and permissions properly on two separate servers.

  • AlwaysOn (AO for short) enables you to have up to four read-only copies of the primary databases. Presumably these might be geographically dispersed. AO enables you to combine multiple databases in a single failover group, called an Availability Group (awkward to say, but nice to have.) You can even choose between having Synchronous vs Asynchronous connections, but there I go again, digressing. We’ll save that for another Byte…
  • FileStream data type. Most SharePoint data is in the form of Binary Large Objects, blobs for short. Blobs are far and away the fastest way to store documents. In effect, it’s just copying a file to a disk. You don’t have to format it or create rows or keep indexes like you do with data.  Until now, though, the problem with blobs is that they were o/s files which were added by SQL. SQL could always find them, but then so could anyone else with the appropriate permissions. And they could read them. This gave DBAs and system administrators much insecurity. Filestreams are handled differently. They are still just files, but they are stored with the SQL Server shell and can only be accessed by going through SQL Security. So they are very secure. FileStream datatypes should dramatically speed up document insertion and retrieval.
  • Much improved BI features such as Power View. Power View is a graphical interface which sits on-top of previously structured data.  Being based on Silverlight, it is used to significantly enhance the appearance of reports.  It’s quite intuitive.  It can cross-reference related data.  So if your report is structured by day, you can quickly reorganize it to be by person or by geographical area.
  • Reporting Services can be directly accessed within SharePoint 2013.  It runs 30-60% faster going through SharePoint.  Reporting Services for 2012 can automatically alert users when data underlying a report has changed.  So if you’re using a report that’s a week old, and sales have slipped 20% since last week, RS can send an alert before you unknowing use it.
  • Data in SharePoint (SQL, Excel, PowerPoint, RS) can be presented in a single dashboard.
  • Because of enhancements in both SQL Server 2012, and in SharePoint 2013, report data is tightly integrated from initial storage to final presentation. So, a user can retrieve SQL Server data into an Excel spreadsheet, structure it via PowerPivot, create a report displaying that data via Power View and display it to PowerPoint. All without leaving SharePoint. Appropriately structured data can have its organization changed in PowerPoint, even if the data is still in SQL – that’s power, err Power View.

Wheww! That tires me out just typing it. This capability dramatically shortens the report generating time and effort.

In a later blog, I’ll use screen shots to visually demo this process.

So, in summary, we’ve noted that:

1.) There are two reasons to choose a newer version of a product:

  • Same costs, more benefits
  • More costs, more benefits worth outweighing the additional costs

2.) That SQL Server 2012 doesn’t cost significantly more that SQL Server 2008 R2, but contains significant additional features.

3.) Most new users are better off with SQL Server 2012 than with SQL Server 2008 R2.

4.) The major benefits of SQL Server 2012 include:

  • It’s newer; 2008 R2 is already being deprecated.
  • It’s faster.
  • It has such features as AlwaysOn, the FileStream data type, tighter integration with SharePoint, and Power View.

That’s all for now; thanks for reading!

Until the Next Byte…

2017-11-09T09:42:26+00:00 September 10th, 2015|


  1. SQL 2008R2 Reporting Services for SharePoint 2013 is not supported | Gokan Ozcifci December 22, 2013 at 11:57 am - Reply
  2. hasan June 25, 2014 at 6:23 am - Reply

    hii Don
    really great

  3. mike September 2, 2014 at 3:53 pm - Reply

    Great article

  4. Ryan Hocking May 21, 2015 at 12:46 pm - Reply

    Also the SSDT SQL Server Data Tools integration with 2012 is far superior to 2008 and works amazingly well! Very powerful tool and worth upgrading just for that.

Leave A Comment