Oracle TimesTen Licensing Guide: Complete Reference for IT Asset Managers

Oracle TimesTen Product Family Overview

The Oracle TimesTen product family consists of three related but separately licensed products. Understanding the distinction between them is the prerequisite for any correct licensing analysis.

Oracle TimesTen In-Memory Database (IMDB)

Oracle TimesTen In-Memory Database is the foundational product: a standalone, fully relational, ACID-compliant database that stores and manages all data in main memory at runtime. It is not a memory cache layer on top of another database — it is a self-contained database product in its own right, with its own data management, query processing, transaction management, persistence, recovery, and replication capabilities.

TimesTen IMDB is designed for applications where response time requirements cannot be met by disk-based systems. The technology delivers sub-millisecond SQL response times and can sustain millions of transactions per second on appropriately provisioned hardware. Common deployment patterns include prepaid telecommunications billing engines, real-time fraud scoring, securities order management systems, authentication and authorisation services handling very high request rates, and telecommunications network element management.

The database resides entirely in shared memory segments managed by the operating system. Persistence is achieved through asynchronous checkpointing to disk-based checkpoint files and transaction log files. If the system fails, TimesTen recovers by replaying the transaction log against the last checkpoint, restoring the database to its pre-failure state. The recovery process operates from memory-speed disk I/O paths and is generally far faster than disk-based database recovery for equivalent data volumes.

Oracle TimesTen Application-Tier Database Cache (IMDB Cache)

The TimesTen Application-Tier Database Cache — commonly called IMDB Cache or the cache product — is a licensed configuration where TimesTen acts as an in-memory cache layer in front of an Oracle Database backend. In this architecture, subsets of Oracle Database tables are synchronised into TimesTen cache groups at the application tier, enabling the application to perform high-speed reads and writes against the in-memory cache while Oracle Database serves as the persistent system of record.

IMDB Cache supports multiple cache group types that govern how data flows between TimesTen and Oracle Database. Read-only cache groups load data from Oracle into TimesTen on demand or periodically, suitable for reference data. Synchronous writethrough (SWT) cache groups propagate writes synchronously to Oracle before confirming the transaction, ensuring consistency at the cost of latency. Asynchronous writethrough (AWT) cache groups confirm writes to the TimesTen cache immediately and propagate to Oracle asynchronously in the background, delivering the highest write throughput for applications that can tolerate brief data discrepancy.

IMDB Cache is a separately licensed product from standalone TimesTen IMDB, and the licencing rules for IMDB Cache include an additional dimension: the relationship between the TimesTen cache licence and the Oracle Database licence that the cache sits in front of.

Oracle TimesTen Scaleout

Oracle TimesTen Scaleout is an extension of the TimesTen architecture that enables horizontal scaling of the in-memory database across a distributed cluster of nodes. In the Scaleout configuration, data is automatically sharded across multiple TimesTen instances, and the cluster can grow by adding nodes without application changes. TimesTen Scaleout is relevant for workloads that exceed the memory capacity of a single server and require elastic horizontal growth.

TimesTen Scaleout uses the same Processor and Named User Plus licensing metrics as the standard product, but the licence requirement must cover all nodes in the cluster — all physical processor cores across all participating hosts require licence coverage.

Licensing Metrics in Detail

All three TimesTen products are available under Oracle's standard Processor and Named User Plus (NUP) metrics. The rules governing each metric follow Oracle's general licensing policy with product-specific minimum requirements.

The Processor Metric

Under the Processor metric, Oracle requires a licence for each physical processor core in the servers where TimesTen is installed, after the application of Oracle's core factor table. The core factor is a multiplier that Oracle assigns per processor type, and it converts physical core counts to the licence count Oracle recognises.

The core factor table assigns the following common values: Intel or AMD x86 processors — 0.5 (two physical cores equal one licence); Intel Itanium — 0.5; IBM POWER — 1.0; IBM z/Architecture — 0.5 per core per software engine; Sun UltraSPARC T — 0.25; and Sun UltraSPARC T2/T2+ — 0.5. For Intel and AMD servers, which represent the large majority of TimesTen deployments, the practical effect is that a dual-socket server with 32 physical cores per socket (64 cores total) requires 32 Processor licences.

Hyper-Threading and other simultaneous multithreading technologies that create logical processor threads are not counted. Only physical cores are counted and then multiplied by the core factor. This is a documented, consistent Oracle policy across all database products.

The list price for a TimesTen Processor licence is $23,000. Annual support is 22% of the net licence purchase price — noting that Oracle has historically exercised an 8% per-year uplift on support fees, meaning that from the baseline year, support costs increase by 8% annually on a compounding basis.

The Named User Plus Metric

Under the Named User Plus (NUP) metric, every individual person or automated device that accesses the TimesTen database must be licensed. Oracle's standard NUP minimum for Oracle TimesTen is 25 Named User Plus licences per Processor. This minimum floor means that NUP licensing is only economically advantageous relative to Processor licensing when the actual user count is well below the 25-per-processor threshold.

The NUP list price for TimesTen is $460 per named user. To illustrate the metric choice economics: a server with 16 physical cores at Intel x86 core factor 0.5 represents 8 Processor licences. The NUP minimum for this server is 8 × 25 = 200 Named User Plus licences. If the organisation has 100 actual named users, the NUP cost is 200 × $460 = $92,000 (minimum applies, not actual user count), compared to the Processor cost of 8 × $23,000 = $184,000. NUP wins. If the organisation has 300 named users, Processor ($184,000) is significantly cheaper than NUP at actual count ($138,000 at list).

A critical error organisations make with NUP licensing is counting only actual users without applying the minimum floor. Oracle enforces the floor rigorously, and audit findings that reveal NUP counts below the minimum are remediated by Oracle at the difference between actual NUP purchased and the minimum required, at full list price plus back-support fees.

IMDB Cache Licensing Rules

The TimesTen Application-Tier Database Cache introduces licensing rules beyond the standard Processor/NUP framework, because it involves an interaction between TimesTen and an Oracle Database licence.

Metric Alignment Requirement

Oracle's licensing policy requires that when TimesTen IMDB Cache is deployed in front of Oracle Database, the TimesTen licence metric must match the Oracle Database licence metric. If the Oracle Database is licensed on Processor, TimesTen must also be licensed on Processor. If Oracle Database is licensed on NUP, TimesTen must be licensed on NUP with at least as many NUP licences as the Oracle Database deployment.

This metric alignment rule is frequently violated in real-world deployments, particularly in organisations where the Oracle Database and the TimesTen layer were procured at different times by different procurement teams, or where the TimesTen deployment was added as a performance optimisation after the Oracle Database was already sized and licenced. The result is a licence mismatch that Oracle treats as a compliance gap.

Oracle Database Licence Independence

Licencing TimesTen IMDB Cache does not provide, replace, or include Oracle Database licence rights. The Oracle Database being cached requires independently maintained Oracle Database Enterprise Edition licences appropriate to the deployment. Common organisational misunderstandings in this area include the belief that the TimesTen cache licence covers the Oracle Database it caches, or that if TimesTen handles all application queries, the Oracle Database (which receives only background propagation traffic) does not need to be fully licenced.

Oracle's position is unambiguous: the Oracle Database in an IMDB Cache architecture requires full licence coverage regardless of whether the application directly queries it or whether the queries are mediated through the TimesTen cache layer.

Options and Packs on the Oracle Database

Certain Oracle Database options and management packs may be implicitly used by TimesTen IMDB Cache features. Organisations should verify that any Oracle Database options that are activated as a consequence of the IMDB Cache configuration — including Advanced Replication, Streams, or other integration technologies — are properly licenced on the Oracle Database side.

Virtualisation Licensing Rules

Oracle's approach to virtualisation licensing for TimesTen follows the same framework that applies to Oracle Database and other Oracle technology products. Understanding this framework correctly is the single largest compliance risk factor in TimesTen deployments.

Soft Partitioning

Oracle classifies most commercially available hypervisors as soft partitioning technologies. This includes VMware vSphere and vCenter, Microsoft Hyper-V, Red Hat KVM/RHEV, Citrix XenServer, and Docker/Kubernetes containerisation platforms. Under Oracle's policy, soft partitioning does not limit licence requirements.

The practical consequence is that if TimesTen is installed in a virtual machine that can be migrated, vMotioned, or otherwise moved between physical hosts within a cluster, Oracle requires licensing of all physical processor cores across every host in that cluster — regardless of the current location of the VM and regardless of whether the VM has actually run on all hosts. The licence requirement is determined by the maximum footprint the VM can occupy, not its current or historical footprint.

This rule is the source of the most common and highest-value TimesTen licence gaps. An organisation that installs TimesTen in a two-host VMware cluster but licences only the cores of the host where the VM currently resides has potentially licenced only half of what Oracle requires. If the cluster grows to eight hosts and the VM can migrate to any of them, Oracle requires licensing of all eight hosts' cores — even if TimesTen has never actually run on six of them.

Hard Partitioning

Oracle recognises a limited set of technologies as hard partitioning, where the licence requirement is genuinely limited to the physical resources allocated to a specific partition. Approved hard partitioning technologies for Oracle products include: Oracle VM for SPARC (LDOMs/LDoms) on SPARC hardware, IBM LPAR with Dynamic System Domains disabled on IBM POWER, Oracle Solaris Zones (non-global zones under specific conditions), HP-UX nPars and vPars in specific configurations, and Oracle VM Server for x86 when properly configured with pinned vCPUs.

For the Intel/AMD x86 server environments where most TimesTen deployments run, Oracle VM Server for x86 is the primary approved hard partitioning option. However, Oracle VM for x86 is not widely adopted in enterprise environments, and the operational constraints it imposes (particularly around live migration and high availability) often make it impractical for the high-availability TimesTen architectures that mission-critical applications require.

Bare-metal installation is always a valid approach to hard partitioning: if TimesTen is installed on a dedicated physical server that does not participate in a virtualisation cluster, the licence requirement is limited to the cores of that specific server.

High Availability Licensing

TimesTen supports high availability through active-standby replication, where a pair of TimesTen databases replicate in real time, and the standby can take over operations if the active fails. Understanding the licensing implications of HA configurations is important for correct compliance management.

Active-Standby Pair Licensing

In an active-standby TimesTen configuration, Oracle requires licences for both the active and standby servers. The standby database is a fully functional TimesTen installation — it processes replication traffic, maintains the database state, and must be able to accept transactions immediately upon failover. Oracle does not provide a discounted or reduced standby licence for TimesTen, unlike some other Oracle products where disaster recovery provisions apply.

This means that a two-node active-standby TimesTen deployment on identical 32-core Intel servers requires 32 Processor licences (16 cores × 0.5 factor × 2 hosts), at a list cost of $736,000. Annual support at 22% adds $161,920, and support grows by 8% per year. The TCO calculation for TimesTen HA deployments over a five-year period frequently surprises organisations that did not factor both nodes into the initial licence count.

Scaleout Cluster Licensing

For TimesTen Scaleout deployments, Oracle requires Processor licences for all nodes in the distributed cluster. As the cluster is scaled out by adding nodes, the licence requirement grows proportionally. There is no incremental volume pricing or cluster discount built into the standard Oracle Technology Price List — licence costs scale linearly with the number of nodes and their core counts, unless a specific Unlimited Licence Agreement (ULA) or Perpetual Unlimited Licence Agreement (PULA) covers the TimesTen product.

Support Fees and the Compounding 8% Increase

Oracle charges annual support fees at 22% of the net licence purchase price for TimesTen. This baseline is compounded by Oracle's practice of applying an 8% annual support fee increase. The compounding effect of 8% annual growth on the support baseline means that support costs approximately double every nine years from the original purchase. For organisations that purchased large TimesTen estates in the early 2000s when the technology was first widely adopted in telecommunications, current annual support fees may represent three to four times the initial annual support fee in nominal terms, even before considering the original licence cost.

The cumulative support fee over the lifecycle of a TimesTen deployment can, and frequently does, exceed the original licence purchase price. For a $1 million TimesTen licence purchase, a ten-year support trajectory at 22% initial rate with 8% annual increase produces cumulative support payments that substantially exceed the $1 million initial licence investment.

This trajectory creates a strong commercial case for proactive support cost management, particularly for organisations whose TimesTen deployments are stable and have no near-term upgrade roadmap. Options include negotiating a multi-year support price cap at the next renewal, evaluating third-party support coverage where available, or assessing whether the TimesTen workload can be migrated to an alternative platform as part of a TCO-driven modernisation programme.

ULA and PULA Coverage for TimesTen

Organisations with an Oracle Unlimited Licence Agreement (ULA) or Perpetual Unlimited Licence Agreement (PULA) that includes TimesTen products can deploy TimesTen without counting licences during the ULA term. This is a material benefit for organisations with growing or unpredictable TimesTen deployment footprints.

However, ULA coverage for TimesTen requires explicit inclusion of the TimesTen product names in the ULA schedule. A ULA that covers Oracle Database Enterprise Edition does not automatically cover TimesTen — TimesTen is a separate product line and must be listed explicitly. Organisations should verify their ULA schedules to confirm which specific TimesTen products are included before deploying under the assumption of ULA coverage.

At ULA certification — the point where the customer declares their deployment count and converts to perpetual licences at that count — the TimesTen deployment must be fully and accurately reported. Deployment maximisation during the ULA period is the standard strategic advice: since all TimesTen deployment during the ULA term is licence-free (support fees still apply), organisations should deploy as much TimesTen as they legitimately need before certification. Every additional TimesTen server added during the ULA term increases the perpetual licence count captured at certification at zero incremental licence cost.

Common Audit Findings and How to Prevent Them

Based on advisory work across telecommunications, financial services, and manufacturing sectors, the recurring TimesTen compliance findings include the following patterns.

VMware cluster exposure: TimesTen installed in a VMware HA cluster with only the current host licenced rather than all cluster hosts. This is consistently the highest-value gap and the most common single finding in TimesTen licence audits. Remediation requires either purchasing licences for all cluster hosts or migrating TimesTen to a bare-metal or hard-partitioned environment.

HA standby not licenced: The standby node in an active-standby TimesTen deployment was treated as a backup that did not require licensing. Oracle requires full licence coverage for all nodes in a TimesTen HA pair regardless of active/standby status.

IMDB Cache metric mismatch: TimesTen IMDB Cache was licenced on Processor while the Oracle Database backend was licenced on Named User Plus, or vice versa. Oracle requires metric consistency, and the remediation is conversion to a consistent metric — which almost always results in higher costs since the customer must move to the more expensive metric to achieve compliance.

Dev/test/staging environments unlicenced: TimesTen installed in development, quality assurance, and staging environments without separate licence coverage. Oracle's licence terms require all installations to be licenced unless a specific development or restricted-use licence applies. TimesTen does not have an embedded or development licensing exemption comparable to some other Oracle products.

Scaleout cluster partial coverage: Only some nodes in a TimesTen Scaleout cluster were licenced. The distribution of data across all cluster nodes constitutes deployment on all nodes, and all nodes require full licence coverage.

Ten Recommendations for TimesTen Licence Management

1. Conduct a full deployment inventory: Document every TimesTen installation across all environments, including development, QA, staging, production, and DR. Include all virtualisation configurations and the full cluster membership for any virtualised deployments.

2. Apply core factor correctly: Verify that the Processor count was calculated using Oracle's current core factor table applied to physical core counts only. Re-verify when servers are upgraded or virtualisation configurations change.

3. Verify IMDB Cache metric alignment: If you run TimesTen IMDB Cache, confirm that the TimesTen metric matches the Oracle Database metric and that the NUP count (if applicable) meets the minimum per-processor floor.

4. Confirm Oracle Database coverage for IMDB Cache: Independently verify that the Oracle Database instances being cached are correctly licenced for their deployment. IMDB Cache does not license the underlying Oracle Database.

5. Audit virtualisation cluster membership: For any TimesTen installation in a VMware or other virtualised environment, document all hosts in the cluster and confirm that all have been included in the Processor count. Update this analysis whenever the cluster configuration changes.

6. License HA standby nodes: Include both active and standby nodes in your TimesTen Processor or NUP count. There is no standby discount or exception for TimesTen HA configurations.

7. Check ULA/PULA schedule for TimesTen: If you hold a ULA or PULA, verify that the specific TimesTen products you are deploying are listed in the ULA schedule. Do not assume Oracle Database ULA coverage extends to TimesTen.

8. Maximise deployment before ULA certification: If you are within a ULA term that covers TimesTen, deploy all planned TimesTen infrastructure before the certification date. Post-certification deployments require new licence purchases.

9. Negotiate support price caps at renewal: Oracle's 8% annual support increase is contractually applied but negotiable at renewal time. Multi-year price caps are achievable with the right commercial approach and create significant cumulative savings over a five-year period.

10. Engage independent advisory before Oracle engagement: Whether responding to an audit, approaching a renewal, or planning a deployment change, independent Oracle licensing advisory identifies risks and opportunities that internal teams and Oracle's own commercial teams consistently miss.