Db2 12.1.5 was officially released earlier this month and I have been going through the release notes with interest. As always, there is a lot in a mod pack, IBM have published the full details over at the official IBM documentation page, and I would encourage anyone running Db2 12.1 to work through it properly before planning their upgrade. But rather than just re-listing everything, here are the features that caught my eye, the ones I think will make a genuine difference day-to-day.
DiskANN Vector Indexing
Db2 has had the VECTOR data type since 12.1.2, but without indexing, similarity search meant a full table scan. Whilst this is fine for R&D proof of concept, it’s a problem you do not want in production. 12.1.5 fixes that with DiskANN-powered vector indexes. DiskANN is a graph-based approximate nearest-neighbour algorithm designed to work efficiently on disk, so you’re not constrained to keeping the entire index in memory. That makes it practical for real-world dataset sizes. Semantic search, recommendation engines, retrieval-augmented generation (RAG), all of these patterns become genuinely viable on Db2 now, without bolting on a separate vector database alongside your existing estate. One data platform, one security boundary, one set of operational tooling. That’s a compelling argument for me.
High Availability
The maximum number of standbys can now be more than 3, and up to 31. You can now build cascading HADR topologies spanning multiple geographic regions, with dedicated standbys for reporting workloads sitting alongside your DR chain, a welcoming flexibility for organisations with global footprints or strict data residency requirements. I need to ask Mike Springgay, Chief Db2 Architect at the IBM Toronto labs on “why 31?”, though!
pureScale: Up to 45% Faster Mod Pack Updates
Genuinely useful. IBM’s internal testing shows mod pack updates on Linux running up to 45% faster than before, with AIX also improved. If you are managing pureScale clusters, you will know that mod pack time translates directly into maintenance window size. Shorter windows mean less risk, fewer scheduling headaches, and an easier conversation with the business when you need to apply updates.
RPM-Based Installation for Linux
This one might not generate much excitement in a blog post, but it’s the kind of change that makes a real difference to teams running infrastructure-as-code. Db2 can now be installed via standard Linux package management, rpm, yum, dnf, rather than the proprietary db2_install script. That means Db2 shows up in your package inventory, participates in your standard patching pipeline, and integrates cleanly with Ansible or Terraform without needing custom installation logic. I have been down this road recently, building an Ansible pipeline to install Db2, create an instance, and create a database using the traditional tarball and db2setup approach, and the contrast with native RPM integration will make the process even smoother. I will be writing that up in a separate post. So, watch this space.
Automatic Database Activation for Single-Partition Instances
A small but welcome addition. Db2 single-partition instances can now be configured for automatic database activation, databases come up automatically when the instance starts, without requiring a separate ACTIVATE DATABASE command or a first-connection trigger. In practice this removes a common post-restart step that’s easy to miss in runbooks or automated recovery scripts. For environments where the database needs to be ready immediately after an instance restart, particularly in automated failover or scripted recovery scenarios, this removes a potential gap between the instance being up and the database actually being available.
Monitoring
A handful of monitoring improvements that collectively make the DBA’s life easier:
- MON_GET_TABLE enhancements — additional table properties are now exposed, including data that helps identify inactive or rarely-used tables. Being able to query which tables have not been touched recently is more useful than it sounds. It feeds directly into capacity planning, archiving decisions, and storage optimisation conversations. Running a query to find tables with no read or write activity in the last 90 days is the kind of thing that used to require digging through multiple sources; surfacing it through MON_GET_TABLE makes it routine.
- Revised REORGCHK formulas — the formulas for adaptive compressed and range-partitioned tables have been updated to make reorganisation recommendations more precise. The old formulas were conservative and would sometimes recommend REORG when the performance benefit didn’t justify the I/O cost. The new formulas understand the structure of these table types better, so REORG runs when it actually helps rather than on an arbitrary schedule.
Worth the Upgrade?
For anyone on Db2 12.1, the answer is certainly yes. The HADR and pureScale improvements alone are substantial, and the DiskANN vector indexing is a meaningful step forward if you are building or planning to build AI-driven applications on Db2.
The full ‘what’s new’ list is at the IBM documentation page for 12.1.5, and the mod pack itself is downloadable from IBM Fix Central. As always, test in non-production first and check the known issues before you schedule anything for your critical environments.
If you have any questions, please get in touch:
Email: iqbal.goralwalla@triton.co.uk
Call: +44(0) 870 2411 550
This article was first published via The Triton Perspective, our monthly LinkedIn newsletter. Subscribe on LinkedIn to read future insights first, before they are published on our website.