Executive Summary: IBM DB2 is one of the most widely deployed enterprise database platforms, powering mission-critical transactional and analytics workloads across industries. However, DB2 licensing can be complex, with multiple licensing models, edition tiers, and strict sub-capacity rules that require careful management. This advisory provides IT asset managers with a clear breakdown of IBM DB2 licensing models, edition choices, cost drivers, and common pitfalls, along with actionable guidance to optimise licensing strategy and avoid costly surprises.

For a broader view of IBM licensing across all products, see our IBM Licensing Knowledge Hub.

1. IBM DB2 Licensing Models Explained

IBM offers multiple licensing models for DB2, tailored to fit various enterprise scenarios. The two primary models are Processor Value Unit (PVU) and Authorised User licensing.

PVU Licensing (Processor-Based)

PVU licensing charges per processor core deployed on servers running DB2. Each physical processor core in the server is assigned a PVU value based on processor type and speed. All users accessing the database are covered under a single PVU license pool.

  • How it works: IBM counts all processor cores in the server, applies a PVU multiplier per core, and multiplies by the number of servers. For example, a server with 4 cores at 70 PVU/core equals 280 PVUs required.
  • Suitable for: Large deployments with many concurrent users, high-compute workloads, or organisations wanting per-user simplicity.
  • Cost model: Fixed annual cost per PVU pool, regardless of actual user count or usage patterns.

Authorised User Licensing (User-Based)

Authorised User (AU) licensing charges per named user who can access the database, regardless of how many times they log in or how many servers run DB2.

  • How it works: You purchase a licence for each user who is authorised to use DB2. A single AU covers one user across all servers and databases in the organisation running DB2 Standard Edition.
  • Suitable for: Organisations with small user bases, predictable user populations, or low-concurrency environments.
  • Cost model: Per-user cost, making budgeting more transparent. Total cost scales linearly with user count.

Concurrent User Licensing (Time-Limited)

Concurrent User (CU) licensing is available for DB2 on select platforms. It charges per simultaneous user connected to the database at any point in time.

  • How it works: IBM counts the number of simultaneous connections. If 50 users are logged in simultaneously, you need 50 concurrent user licences, even if 500 users might use the database throughout the day.
  • Suitable for: Batch-processing environments, seasonal workloads, or shift-based work patterns.
  • Cost consideration: Often the lowest-cost option for organisations with low concurrency relative to total user base.

2. DB2 Edition Choices and Licensing Implications

IBM DB2 is available in multiple editions, each with distinct licensing models and feature sets. The edition you choose directly impacts licensing cost and capability.

DB2 Standard Edition

Standard Edition is the foundational offering, designed for departmental and workgroup databases. It supports Authorised User licensing (primary model) or Concurrent User licensing.

  • Features: Basic database functionality, limited high-availability features, single-server deployment.
  • Licensing: Authorised User (minimum 5 users) or Concurrent User (per simultaneous connection).
  • Cost position: Most cost-effective edition for small-to-medium deployments with limited user populations.

DB2 Enterprise Edition

Enterprise Edition is the premium offering for large-scale, mission-critical deployments. It supports both PVU and Authorised User licensing.

  • Features: All Standard Edition features plus advanced partitioning, clustering, workload management, and high-availability options.
  • Licensing: PVU (per processor core) or Authorised User (minimum 25 users; effectively 100 PVUs minimum).
  • Cost position: Significantly higher per-unit cost than Standard Edition, but PVU model scales with compute capacity rather than user count.

DB2 Express Edition

Express Edition sits between Standard and Enterprise. It offers many Enterprise features but with licensing and resource limitations.

  • Features: Partitioning, workload management, and some high-availability features, but limited to smaller deployments.
  • Licensing: Concurrent User or Authorised User only (no PVU).
  • Cost position: Lower cost than Enterprise Edition; bridges the gap for organisations needing Enterprise features but with smaller footprints.

3. Sub-Capacity Rules: What You Must Know

IBM's sub-capacity licensing rules allow organisations to license fewer cores than physically installed, provided they use DB2 on only a subset of processor cores. This is one of the most complex and misunderstood aspects of DB2 licensing.

How Sub-Capacity Works

If your server has 16 physical cores but you configure DB2 to use only 8 cores, you can license only 8 cores (if properly managed through hypervisor or OS limits). IBM calls this "sub-capacity" licensing.

Sub-Capacity Requirements (Strict Compliance)

  • Core limit enforcement: The server hypervisor or operating system must be configured to limit the cores available to DB2. Simply "not using" cores does not qualify for sub-capacity.
  • Documentation: You must document and maintain proof of core limits. This includes hypervisor settings, OS-level affinity masks, or virtualisation layer configurations.
  • Audit readiness: IBM audits sub-capacity licensing rigorously. You must be able to demonstrate core limitation at the time of audit through logs, configuration screenshots, or hypervisor reports.
  • Virtual machine licensing: If DB2 runs on a virtual machine, sub-capacity applies to the VM's allocated cores, not the physical host cores (assuming the hypervisor properly enforces limits).

Common Sub-Capacity Mistakes

  • Assuming soft limits (e.g., DB2 configuration parameters) count as hard sub-capacity limits. They do not. Only OS or hypervisor-level enforcement qualifies.
  • Failing to document core limits. Maintenance records and configuration documentation are essential during an IBM audit.
  • Moving DB2 to a different server without re-evaluating sub-capacity limits. License terms change if you alter your infrastructure.
  • Mixing sub-capacity and standard licensing on the same server without clear separation. This creates compliance complexity and audit risk.

4. ILMT Compliance and Reporting

IBM License Metric Tool (ILMT) is IBM's software inventory and compliance tool. Understanding how ILMT works is critical for DB2 licensing compliance.

What ILMT Does

ILMT scans your infrastructure to detect IBM software installations, map software usage to physical and virtual servers, and generate compliance reports. IBM uses ILMT data during audits to determine whether your deployment matches your licensed position.

DB2-Specific ILMT Challenges

  • ILMT may overcount cores: ILMT can misidentify physical vs. virtual cores, especially in complex hypervisor environments. This can make your deployment appear to require more PVUs than you actually owe.
  • Sub-capacity documentation in ILMT: ILMT does not automatically capture sub-capacity limits. You must manually document and maintain sub-capacity evidence separately from ILMT reports.
  • ILMT gaps with Edition detection: ILMT sometimes struggles to accurately identify which DB2 edition is deployed (Standard vs. Enterprise). Miscategorisation can lead to incorrect compliance calculations.
  • Audit reconciliation: During an IBM audit, ILMT data is often the starting point. Misalignments between your ILMT reports and actual deployment frequently trigger additional audit activities.

Best Practices for ILMT Compliance

  • Run ILMT quarterly and reconcile results with your actual DB2 deployments.
  • Maintain a separate sub-capacity evidence log, including hypervisor settings and core limit documentation.
  • Flag any ILMT anomalies (unexpected installations, core count mismatches) immediately to your licensing team.
  • Provide ILMT reports to your IBM account team annually, even if not requested. Proactive compliance reduces audit risk.

5. Cost Scenarios and Break-Even Analysis

Understanding the financial impact of licensing model choices and deployment decisions is critical. The difference between PVU and Authorised User licensing, and the impact of sub-capacity, can amount to hundreds of thousands of dollars.

Scenario 1: Small Departmental Database (15 Users, 1 Server)

Server: 1 server with 8 x86 cores (70 PVU/core = 560 PVUs total)

Option A (Standard AU): Minimum 5 users required. 15 actual users = 15 AU licences.

Option B (Enterprise PVU): 560 PVUs required (8 cores × 70 PVU/core).

Estimated annual cost (Option A): 15 users × ~$2,000/user = $30,000

Estimated annual cost (Option B): 560 PVUs × ~$80/PVU = $44,800

Winner: Authorised User licensing saves approximately 33% for this scenario.

Scenario 2: Large Enterprise Deployment (500 Users, 10 Servers)

Infrastructure: 10 servers, each with 16 cores (70 PVU/core = 1,120 PVU per server = 11,200 PVUs total)

Option A (Enterprise AU): Minimum 25 users per 100 PVUs. 11,200 PVUs requires minimum 2,800 AU (11,200 ÷ 100 × 25). Actual users = 500, so effective cost for 2,800 AU.

Option B (Enterprise PVU): 11,200 PVUs required (10 servers × 8 cores × 70 PVU/core).

Estimated annual cost (Option A): 2,800 AU × $2,000/user = $5.6M

Estimated annual cost (Option B): 11,200 PVUs × $80/PVU = $896,000

Winner: PVU licensing saves approximately 84% because actual user count (500) is far below the AU minimum commitment.

Scenario 3: Sub-Capacity Optimisation (High-Core Server, Limited DB2 Usage)

Server: 1 server with 32 cores, DB2 configured to use only 8 cores via hypervisor limit.

Option A (Full Licensing): 32 cores × 70 PVU/core = 2,240 PVUs

Option B (Sub-Capacity): 8 cores × 70 PVU/core = 560 PVUs (if sub-capacity limits are properly documented and enforced)

Annual savings with sub-capacity: (2,240 - 560) × $80 = $134,400 per year

Key requirement: Hypervisor must enforce the 8-core limit; operating system logs must show core affinity; and documentation must be audit-ready.

6. Key Takeaways and Optimisation Strategies

1. Match Licensing Model to Usage Pattern

PVU licensing favours high-core, low-user deployments. Authorised User licensing favours low-core, high-user deployments. Analyse your actual user count and infrastructure before defaulting to PVU.

2. Sub-Capacity is Only Worth Pursuing with Proper Documentation

Sub-capacity optimisation can save hundreds of thousands of dollars, but only if core limits are enforced at the hypervisor or OS level and properly documented. Without documentation, IBM may disallow sub-capacity during audit.

3. ILMT Compliance Requires Active Management

Run ILMT quarterly, reconcile with actual deployments, and flag anomalies immediately. ILMT data is the foundation of IBM audit defence.

4. Edition Selection Impacts Long-Term Cost

Standard Edition is cheaper per unit but more restrictive. Enterprise Edition is more expensive but offers scaling flexibility through PVU licensing. Choose based on your actual workload requirements and growth trajectory.

5. Audit Risk Reduction Through Proactive Compliance

Organisations that maintain accurate ILMT reports, document sub-capacity limits, and align deployment with licensing agreements face significantly lower audit risk. Proactive compliance reduces legal exposure and negotiation complexity during audit.