The lead-in
Friend and colleague Bruce Momjian already shared in his presentation “Will Postgres live forever?” (https://attendee.gotowebinar.com/register/8793191803818201345) an overview of reasons why companies adopt open source software (OSS) in general. This overview was based on a survey done by Black Duck Software in 2016 (https://www.slideshare.net/mobile/blackducksoftware/2016-future-of-open-source-survey-results). The survey ranks databases on the second place of technologies that companies are moving towards OSS in.
In this series of short blogpost I want to highlight some of the practical cases of Postgres adoption in the Enterprise from our day-to-day practice, and see which of the general factors of OSS adoption we see with Postgres .
IBM DB2 to Postgres
The first of the cases deals with a semi-government organization that currently has an application landscape based on IBM DB2, Microsoft SQL-Server and Oracle. Our primary engagement is to support their move of their application landscape from IBM DB2 to Postgres.
The initial driving force behind this decision was the staggering renewal-cost this organization was facing for their DB2 licenses. These licenses included IBM’s Deep Compression option (https://www.ibm.com/developerworks/data/library/techarticle/dm-1205db210compression/index.html). This option reduces disk-space by as much as 50%. More importantly it reduces database IOPS to meet the performance of the applications. Moving from DB2 on Z/OS to DB2 on Linux, the company faced a performance deficit which they initially resolved by using this Deep Compression option.
This option was also a grounds for worry. Obviously an expensive database option, that was known to bring real benefits to DB2 database performance, would outperform Postgres, right? Would we be able to come near DB2 database performance when running on Postgres?
Discussion with our own Postgres experts could not take away these concerns. We would have to test and validate.
The project had already kicked into gear when EnterpriseDB was engaged. Some of the software had already been migrated and converted to fit on EDB Postgres Advanced Server (EPAS). For much of the data and schema migration, the software by Spectral Core, named Full Convert (https://www.spectralcore.com/fullconvert/).
The outcome
Part of the extensive test-program of the migration project was performance testing, which also included a simulated full pressure practice test with load-generators.
The surprise was then also quite absolute, when the final results of the performance tests were released. EPAS was capable to keep up quite nicely with the original DB2-setup, and even improved performance in some specific tests.
Performance tests concluded, June 28 2018
Test Number | Postgres Runtime |
---|---|
% of original DB2 runtime | |
Number 1 | 87.2 % |
Number 2 | 101.0 % |
Number 3 | 109.4 % |
Number 4 | 79.3 % |
Number 5 | 70.0 % |
Number 6 | 109.5 % |
Number 7 | 106.4 % |
In analysis of this particular project, we can conclude that the reasons for this project to choose Postgres are:
- Primarily #5, Cost reduction. Database running cost on an annual basis can be reduced in access of 80%
- Secondly #2, Freedom from vendor lock-in. Postgres is a community open source solution having no single company controlling the solution.
More details
I am curious to learn what details you would want to read here in order to help you assess your specific situation! Let me know in the comments.