Three Db2 Metrics: PVU, VPC, Authorised User
IBM licenses Db2 under three distinct metrics, and the choice between them is the single largest lever on Db2 cost. PVU counts processor power — the per-core rating multiplied by counted cores. VPC (Virtual Processor Core) counts virtual cores, licensing by vCPU. Authorised User counts named individuals. The same database deployed under the wrong metric can cost several times what it should — which is why metric selection, not discount, is where Db2 optimisation begins.
Most large estates accumulate a mix of all three through years of uncoordinated purchasing, leaving workloads stranded on metrics that no longer fit their shape. The first optimisation step is simply mapping which metric each Db2 deployment runs on against which metric it should run on.
VPC: 20-30% Below PVU in the Cloud
For cloud and modern virtualised deployments — Db2 on AWS, Azure, IBM Cloud, or on-premises virtualisation — VPC rates run roughly 20 to 30% lower than PVU rates for equivalent capacity, because cloud instances are treated as more efficient per core. A 4-vCPU instance carries a 4-VPC obligation, counted directly without the PVU per-core multiplier. For any Db2 workload running on virtualised or cloud infrastructure, VPC is frequently the cheaper metric — yet enterprises routinely leave these workloads on legacy PVU entitlements simply because that is how they were first bought.
| Db2 metric | Counts | Best fit |
|---|---|---|
| PVU | Processor power (rating × cores) | Large on-prem deployments on physical hardware |
| VPC | Virtual cores (per vCPU) | Cloud / virtualised workloads — ~20-30% below PVU |
| Authorised User | Named individuals | Small, bounded, stable user populations |
When Authorised User Wins
Authorised User licensing prices Db2 by named individual, and it is the cheapest metric only where the user population is genuinely small, bounded, and stable — discrete business applications, partner portals, or internal tools with a fixed, accountable user list. For large or concurrent populations it is far more expensive than processor metrics. The error in both directions is common: enterprises put high-user applications on Authorised User and overpay, or put small bounded apps on PVU and overpay. Matching the metric to the real access pattern is the saving.
There is no universally cheapest Db2 metric — only the cheapest metric for a given workload's shape. The money is lost when a deployment is licensed the way it was first bought rather than the way it now runs. Re-map metric to workload, and the savings appear without changing a line of the application.
Edition Right-Sizing: Advanced vs Standard
Db2 ships in tiered editions, and the Advanced editions carry substantially higher per-unit cost for capabilities — compression, advanced security, certain availability features — that a given workload may not use. Enterprises frequently standardise on the Advanced edition estate-wide for procurement simplicity, then pay the premium on databases that only need Standard-edition function. Auditing feature usage against edition and stepping down where the advanced capabilities are unused is a direct, low-risk reduction. The mirror risk — running an unlicensed Community Edition past its capacity limits — creates compliance exposure, so edition right-sizing must run in both directions.
Sub-Capacity and ILMT for Db2
Db2 under PVU is an eligible sub-capacity product, so the savings depend on the same conditions as the rest of the estate: eligible virtualisation, hard capping, and a current ILMT deployment with retained quarterly reports. A Db2 instance hard-capped to 8 cores on a 64-core host should cost an eighth of the full-capacity figure — but only if ILMT proves it. Our ILMT configuration guide and PVU counting guide set out exactly how to protect that position; for cloud Db2 on VPC, the sub-capacity question is replaced by accurate vCPU counting.
A Db2 Cost-Reduction Playbook
A structured Db2 reduction runs five steps: map every deployment to its current and ideal metric; migrate cloud and virtualised workloads from PVU to VPC where the 20–30% saving applies; move genuinely small bounded apps to Authorised User; right-size editions against actual feature usage; and protect sub-capacity with hard caps and current ILMT. Crucially, resolve any PVU-to-VPC misalignment proactively in the second or third quarter — ahead of the typical year-end audit peak — because addressing it before an audit trigger is far stronger than negotiating under one. Layered on the 20–40% discount large enterprises secure through their Passport Advantage relationship or an Enterprise Licence Agreement, these moves compound. To build your Db2 reduction plan, request a confidential briefing.
Timing Db2 Optimisation Around the Audit Calendar
When you optimise Db2 matters almost as much as how. IBM audit activity concentrates toward year-end, so the organisations in the strongest position resolve any PVU-to-VPC misalignment proactively in the second and third quarters — before an audit trigger removes their room to manoeuvre. Fixing a metric mismatch on your own initiative is a routine entitlement adjustment; fixing the same mismatch after an audit notice is a compliance negotiation conducted from the back foot. The calendar, not just the configuration, is a lever.
Build a recurring cycle. Each quarter, verify that cloud Db2 instances are counted accurately on VPC and that any move from PVU to VPC is documented with the supporting infrastructure evidence. Audit edition usage against actual feature consumption and step down where the advanced capabilities sit idle. True-down entitlement at renewal — the contractual moment when reductions are cleanest — rather than mid-term. And align all of this with the ILMT quarterly cadence so the same reports that defend sub-capacity also evidence your metric and edition decisions. Optimisation timed to the audit calendar protects the saving instead of surrendering it.
This guide is one of eleven in our IBM licensing cluster. To connect Db2 to the rest of your IBM estate, read it with the IBM master guide, ELA negotiation, Passport Advantage, sub-capacity PVU counting, ILMT configuration, Cloud Paks licensing, watsonx pricing, mainframe MLC and zIIP, Power Systems and AIX, and subscription migration.
Two Db2 edge cases deserve attention because they catch enterprises out. Db2 Connect, which links distributed applications to Db2 for z/OS, carries its own licensing that is easy to under-count when gateway topologies change. And mixing metrics within a single application estate, some instances on PVU and others on VPC, is permitted but must be documented cleanly, because an auditor who cannot follow the logic will default to the most expensive interpretation. A simple register that records, for every Db2 deployment, its edition, metric, host, cap, and the evidence behind each choice turns an ambiguous estate into a defensible one. That register is also the artefact that makes the next renewal or audit faster, cheaper, and far less stressful to defend.
Where Db2 Licensing Fits
Distributed Db2 economics — governed by PVU, VPC, and ILMT — differ sharply from Db2 for z/OS on the mainframe, where MLC and zIIP offload rule. Db2 also sits inside several Cloud Paks bundles and is increasingly offered under the subscription model, while the data platform extends into watsonx and runs on Power. Read this with the IBM master guide, the IBM vendor hub, and the IBM Licensing Guide white paper.