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


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


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


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


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:

Sybase ASE


Microsoft 2012 Enterprise




PostgreSQL – supported


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


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


MBC Required Functionality




Future Commercial Viability


High Availability




Product Track record/Future stability


Technical Functionality


Architectural Standards and Connectivity


DBMS standard functionality


Data Warehouse standard functionality




DBMS Management Functionality


Ease of Maintenance/Management


Database Configuration


People and Future Flexibility


Future Migration/Flexibility


Standard Technology/People Availability


Performance Functionality


Bulk Load Performance


Bulk Update Performance


Bulk Delete Performance


Basic Query Performance


Cross Product Query Performance


Sub Query Performance


Parallel Query Performance


Analytical Query Performance


Indexed Update Performance


Indexed Delete Performance


Non-Indexed Update Performance




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.


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

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.


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


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


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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: