SQL Server 2012 – Cheaper than Open Source Database options

On a recent project we were tasked to review and recommend a database technology platform for a new Data Warehouse environment. This quickly turned into a database evaluation not just for the new Data Warehouse, but also for all future applications. The client was currently on Sybase, but was open to the most cost-effective option. The client also had experience with Open Source technologies in the past for both server operating systems (linux) and reporting solutions. (JasperSoft)

The criteria we specified had cost and performance as two important factors. Since we had limited experience with any Open Source databases in a Data Warehouse environment, we felt it would be useful to evaluate the options from a cost, functionality, and performance point of view.

This post is a recap of that process and of the somewhat surprising recommendation.

The Candidates

Since the client already was using Sybase, it was a no-brainer to include that one. It addition to Sybase, we included SQL Server and Oracle from the commercial DBMS’s due to their market share and existing use at the client. DB2 was excluded due to DB2 not currently being used at the client and the perceived higher cost of implementation of DB2. (Rightly or wrongly) It was felt that either Oracle or SQL Server could represent the commercial DBMS’s.

On the Open Source side, the DBMS’s MySQL and PostgreSQL were selected. MySQL was selected due to its large adoption in the Open Source community and recognition for performance. PostgreSQL was selected also for its recognition in the Open Source community for robustness and performance. MySQL and PostgreSQL were the only two Open Source DBMS’s as it was felt they were the clear leaders in the Open Source DBMS’s.

After performing detailed performance tests between MySQL and PostgreSQL, PostgreSQL was chosen as the Open Source DBMS option to compare against commercial DBMS’s. This was due to the fact that MySQL had significantly poorer performance when using the InnoDB engine that guaranteed ACID compliance and provided referential integrity. MySQL has an interesting piece of functionality to allow you to use different database engines that provide different functionality and types of processing. Unfortunately the engine used in many of the published benchmarks do not provide the functionality required by standard enterprise DBMS solutions.

The Requirements

The current Data Warehouse requirements were reviewed and it was determined that the vast majority of the reporting requirements were operational reports delivered in text format. This is probably not unlike many companies out there that are early in the use of Data Warehouses. This is not to preclude the use of more analytical functions in the future, but that was not the use of the Data Warehouse currently.

The current Data Warehouse also stored data in the 10’s of gigabytes. So although this was a considerable amount of data, it also did not require advanced Data Warehouse appliances or Big Data solutions. Traditional Data Warehouse architecture and designs would be sufficient for now and well into the future.

The requirement was that the Open Source solutions must be supported. For example, this meant that we would require support from EnterpriseDB if we chose PostgreSQL. I propose this is pretty typical for larger companies evaluating Open Source.

The Architecture

Due to the current requirements and expected future requirements, the recommended Data Warehouse solution architecture was designed to incorporate both an Operational Data Store and a Star Schema Data Warehouse. The Operational Data Store would be used to generate pure operational reports and would be loaded at least daily. The Star Schema Data Warehouse would be used to generate more analytical reports and would be loaded on a weekly basis.

The Evaluation

The recommended configuration for the evaluation was for two servers each with two Quad core CPUs. This was due to the current workload and the expected increased workload in the future. We did evaluate higher levels of configuration to ensure the cost was linear for future growth.

This was not a small Data Warehouse and is probably typical of most enterprises as an entry into Data Warehouse technology.

We separated our cost evaluation into two sections:

1)       Initial Cost

2)      Ongoing Cost

Initial Cost

Initial cost incorporated the server and DBMS license fees for both development and production environments and also two human factors:

Training – What is the cost of the initial training required for the administrators.

Efficiency – What is the expected efficiency for the administrators in the first three months.

The results can be seen below:


As you can see, the supported PostgreSQL option was significantly more affordable as far as initial cost.

Annual Cost

The Annual cost incorporated the following two factors:

License Support costs – These costs are the support and maintenance costs for both the Production and Development environments.

Estimated Annual Maintenance Costs – It is estimated that there will be additional ongoing effort to maintain the different DBMS solutions as compared to the current Sybase solution. This is due to the different complexities of the DBMS solution, the available tools for the DBMS solution, and the available support in the DBMS user communities.

  Estimated Annual Maintenance Rating Rationale
Sybase ASE

0%

No additional maintenance effort is required due to the fact that Sybase is currently used
Microsoft SQL Server 2012 Enterprise

5%

No additional maintenance effort is required due to the fact that Microsoft has an excellent set of tools and resources and the environment is similar to Sybase which is currently used

Baseline 5% additional cost has been added to account for the fact that a second DBMS must now be learned and supported.

Oracle 11

20%

Additional maintenance effort of 15% is estimated due to the complexity and toolset for Oracle.

Baseline 5% additional cost has been added to account for the fact that a second DBMS must now be learned and supported.

PostgreSQL – supported

10%

Additional maintenance effort of 5% is estimated due to the simplicity of the PostgreSQL solution and the relatively limited toolset and resources.

Baseline 5% additional cost has been added to account for the fact that a second DBMS must now be learned and supported.

The results can be seen below:

As you can see, the annual ongoing costs end up being in favour of SQL Server.

The 10 year Total Cost of Ownership (TCO) is:

DBMS Cost
Sybase ASE

$1,173,057.20

Microsoft 2012 Enterprise

$1,019,909.00

Oracle

$4,040,910.00

PostgreSQL – supported

$1,074,025.00

Although SQL Server has an initial license cost, the ongoing support costs are less than supported PostgreSQL in almost all categories.

Conclusion

Over a ten-year period, the TCO for SQL Server is less than a supported version of PostgreSQL. This also includes the server licensing costs. As an added benefit, our solution also required a Reporting Solution and an Extract, Transform, and Load solution – SQL Server provides both of these solution bundled with the DBMS for no additional cost.

From a cost perspective, SQL Server is the clear winner.

For our situation, although cost was important, it was not the overriding factor. In fact, cost accounted for only 10% of the entire weight. The factors and their weights are listed below:

Evaluation Criteria

Weight

MBC Required Functionality

350

Cost

100

Future Commercial Viability

100

High Availability

50

Scalability

50

Product Track record/Future stability

50

Technical Functionality

350

Architectural Standards and Connectivity

50

DBMS standard functionality

100

Data Warehouse standard functionality

150

Security/Encryption

50

DBMS Management Functionality

50

Ease of Maintenance/Management

30

Database Configuration

20

People and Future Flexibility

50

Future Migration/Flexibility

20

Standard Technology/People Availability

30

Performance Functionality

200

Bulk Load Performance

20

Bulk Update Performance

20

Bulk Delete Performance

10

Basic Query Performance

20

Cross Product Query Performance

20

Sub Query Performance

20

Parallel Query Performance

20

Analytical Query Performance

20

Indexed Update Performance

20

Indexed Delete Performance

20

Non-Indexed Update Performance

10

Total

1000

After all the factors were evaluated, SQL Server finished 196 points ahead of PostgreSQL.

SQL Server was selected and I was enlightened. Although people assume Open Source DBMS’s are the most inexpensive options, SQL Server is the leader once you include other factors. In fact, SQL Server was the leader in both cost and functionality.

SQL Server Integration Services (SQL Server’s ETL solution) and SQL Server Reporting Services (SQL Server’s Reporting solution) were NOT included in this comparison. If they were, the results would have been even more pronounced.

I encourage you to do your own evaluations. You may be surprised at the results. I know I was.

Please let me know if anyone is interested in specific evaluation criteria. I’d be happy to share our rationale and SQL performance scripts.

8 thoughts on “SQL Server 2012 – Cheaper than Open Source Database options

  1. Soooo, Over the span of 10 years Postgresql, Oracle, and DB2 continue to have an additional 5% maintenance cost because … no one ever learns how to use it? Nice graphs and all, and the customer did what you wanted, but there is kind of a big chunk of mystery math x 10 years there.

    • The numbers can be debated, but in my experience DB2, Oracle, and Postgres have a higher cost due to the complexity of the product and availability of online resources.

  2. I’ve avoided Windows Server and MS SQL Server for years. There is a steep learning curve for both of those products. My numbers would look very different because I’d need to take into account my inexperience with these proprietary products. For estimated maintenance costs, I’d need to add another 5% to the MS SQL side and yet another 5 to 10% for the Windows Server that MS SQL runs on. A Windows Server requires anti-virus which costs anywhere from $400 to thousands annually, depending upon the product. That would also need to be factored in.
    I appreciate your article but there are several items that have been left out of the study, imo.

    • Thanks for the comment Alex. You make a good point about Windows Server. Windows Server was never an issue for us as we already had many Windows Servers and were already supporting the technology.

      What DBMS technology are you currently using? I’ve found the SQL Server learning curve was small compared to Oracle, Sybase and DB2…

  3. 10 years is a long time, lots of things change in 10 years.

    For example I found a comparison of MS SQL 2012 and PostgreSQL 9 on the Microsoft website.

    That was PostgreSQL 9.0 obviously, because why even compare Microsoft most recent offering against PostgreSQL most recent offering at that time ? There was at least 9.1 out at that time. 9.2 came out later that year.

    Lots of things Microsoft claimed PostgreSQL didn’t have were already available in 9.1 and 9.2 checks lots of the other boxes. 9.3 is planned for the third quarter even more can be checked of that list.

    My point is, 10 years is a long long time. PostgreSQL development is going faster and faster.

    I’m no expert in data warehousing though.

    For data warehousing you might want to look at Amazon/AWS RedShift which based on PostgreSQL.

  4. I think that this very good write up. They made decision based on weighted criteria for their environment. Just as PostgreSQL is not static Windows and MS SQL are not static. They may need to do a middle life eval in 4-5 years and see if the direction has changed. As an example they might acquire more PostgreSQL experience and admins. PostgreSQL might have better tools. Their also could be complete shift as as in memory database like SAP HANA become more common place.

  5. It is an interesting article. I’m not sure that I agree with some of the fudge factors but I have no real evidence to push in the other direction. One thing I take issue with is the linear approach to maintenance cost over the years. You’ve marked that deploying a new database technology will require additional training and so deviating from sybase results in an added cost. After a couple of years these numbers should drop off. The learning would be done and people would be as competent with technology X a with sybase.

    I have no idea that licensing for SQL server – really all the closed source databases – was so prohibitive.

  6. Pingback: Prairie Dev Con 2015 – SQL Server is cheaper than Open Source #FTW | Agile Voyageur

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s