When powering mission-critical business applications, databases need to deliver both high performance and reliability. IBM® Db2® is known for its robust support for transactional and analytical workloads for decades. However, with the rise of open source databases, such as PostgreSQL, which are gaining increasing traction, it’s important to understand how these 2 systems can stack up in transactional scenarios.
Let’s look into the performance of IBM Db2 12.1 compared to PostgreSQL in testing for transactional workloads, using cloud-based AWS EC2 environments to level the playing field. Our benchmark of choice for our testing was derived from the widely used TPC-E workload1, designed to simulate the complex operations of a brokerage system. The results? IBM’s Db2 12.1 outperforms PostgreSQL in transactional workloads, delivering up to 5.4X better performance at scale.
To conduct a fair comparison, we focused on a transactional workload derived from the TPC-E benchmark. This benchmark is recognized for its ability to simulate high-volume transactional operations in environments where data is built up over time. The workload mimics the dynamic transactions of a real-world brokerage system, ensuring that both databases were tested under realistic conditions.
For consistency, we used the best available benchmark kits for both Db2 and PostgreSQL. Db2 was tested with our internal DTW2 kit*. For PostgreSQL, we used the open source DBT-5 kit. Naturally, the 2 kits had differences, so to drive a level comparison, we implemented several modifications, from using the same seeding data and database schemas to adjusting the database scale. The goal was to make sure that both Db2 and PostgreSQL had no unfair advantage because of how the workload was implemented.
Performance results: Db2 outshines PostgreSQL
The test results were telling. Across all scales, Db2 outperformed PostgreSQL—sometimes by a significant margin. Even at the small scale, Db2 delivered 2.1 times better performance and at larger scales, this gap widened even further. For instance, at the largest scale, Db2 was 5.4 times faster than PostgreSQL. This demonstrated that Db2 continues to scale efficiently even as workload complexity increases while PostgreSQL does not.
Here’s a breakdown of the results:
As you can see, Db2 not only delivers faster performance at every scale in testing, but it also does so with better CPU efficiency and lower IO wait. In contrast, PostgreSQL showed increased CPU usage (an indication of inefficient resource utilization), especially at larger scales.
The key to Db2’s superior performance lies in its optimized architecture and advanced features such as the AI cost-based query optimizer. Also, Db2’s use of advanced indexing strategies, efficient storage management and built-in compression technologies enable it to handle large-scale transactional loads with ease.
Conversely, PostgreSQL, while an excellent database in many respects, faced challenges in this benchmark. Even with optimizations to the DBT-5 kit, including changes to stored procedures and database schema, PostgreSQL could not match Db2’s performance, particularly as the workload scaled.
One of the most impressive findings of this study is how well Db2 scales compared to PostgreSQL. As the database size increased, Db2 maintained high performance, while PostgreSQL struggled to keep up. For example, at the largest scale, Db2 was 5.4 times faster than PostgreSQL and maintained low CPU usage while minimizing IO wait. As the scale increased, PostgreSQL was not able to handle the increased data volume as efficiently. This was evident from a significantly higher CPU utilization per throughput ratio.
The results of our performance testing clearly show that IBM Db2 12.1 outperforms PostgreSQL in every key metric when simulating transactional workloads. Whether you're dealing with small-scale applications or large enterprise environments, Db2 can scale seamlessly and achieve exceptional performance, all while maintaining efficient resource usage.
Db2’s high performance, scalability and enterprise-ready features make it the clear choice for businesses that rely on database systems to support their mission-critical applications. As workloads grow, the advantages of Db2 become even more pronounced, making it an ideal database for modern, data-intensive enterprises.
If you’re considering a robust, high-performance database for your transactional workloads, Db2 should be at the top of your list.
We surveyed 2,000 organizations about their AI initiatives to discover what's working, what's not and how you can get ahead.
IBM® Granite™ is our family of open, performant and trusted AI models, tailored for business and optimized to scale your AI applications. Explore language, code, time series and guardrail options.
Access our full catalog of over 100 online courses by purchasing an individual or multi-user subscription today, enabling you to expand your skills across a range of our products at one low price.
Led by top IBM thought leaders, the curriculum is designed to help business leaders gain the knowledge needed to prioritize the AI investments that can drive growth.
Want to get a better return on your AI investments? Learn how scaling gen AI in key areas drives change by helping your best minds build and deliver innovative new solutions.
Learn how to confidently incorporate generative AI and machine learning into your business.
Dive into the 3 critical elements of a strong AI strategy: creating a competitive edge, scaling AI across the business and advancing trustworthy AI.
1for PostgreSQL we used the DBT-5 kit, and for Db2 we used our own internal implementation of the TPC-E kit, internally named DTW2. And to drive equivalency in the comparison, we made three changes to the kits: i) same seed data ii) same database schemas (This included adding some indexes that were not present in the PostgreSQL kit, and also adding INCLUDE clauses to some of the indexes. When running the workloads based on TPC-E there is no requirement or suggestion on the indexes to use, so it is up to the implementer to decide the best indexes) iii) same Database Scale: so that the environments where balanced in terms of CPU and IO we experimented with the Initial Trade Days parameter to scale the database and settled on using 60 ITD instead of 300 ITD that is commonly used for TPC-E runs