As Maximo professionals, we often make a simple assumption: the record with the highest ID must be the most recently created. In a traditional single-server environment, that assumption may appear to hold true most of the time.  
‍

However, in IBM Maximo Application Suite (MAS) Manage, especially when running multiple pods, that logic can lead to incorrect conclusions.
‍

Understanding how Maximo manages database sequences, caches values, and assigns IDs across multiple pods is essential for architects, developers, report writers, and integration teams.

Understanding Maximo Sequence Management

Maximo relies on database sequences to generate unique identifiers for records such as:

• Work Orders

• Service Requests

• Inventory Transactions

• Purchase Transactions

• Custom business objects
  ‍

The implementation varies slightly depending on the database platform.

Oracle and Db2

Oracle and Db2 use native database sequence objects. The database itself manages the sequence and guarantees uniqueness across all application instances.
‍

When Maximo needs a new identifier, it requests the next value directly from the database sequence.

SQL Server

Historically, Maximo on SQL Server used the MAXSEQUENCE table rather than native SQL Server sequence objects.
‍

In more recent MAS Manage releases, SQL Server can leverage native SQL Server sequences using the NEXT VALUE FOR mechanism when configured appropriately.
‍

Regardless of the database platform, the key objective remains the same:

Generate unique values efficiently and safely in a highly concurrent environment.

Do Multiple MAS Manage Pods Share the Same Sequence?

The short answer is yes.
‍

In MAS Manage, all pods connect to the same shared database. As a result, they also share the same underlying sequence objects.
‍

A sequence does not exist independently within individual pods. Instead:

• The sequence resides in the database.

• Every pod requests values from the same sequence.

• The database guarantees uniqueness.

• Multiple pods can generate records simultaneously without collisions.
  ‍

This means that UI pods, Integration pods, Cron pods and Reporting pods all consume values from the same underlying sequence source.

What’s the Cache? (See what I did there?)

To improve performance, Maximo does not typically request a new sequence value from the database every time a record is created.
‍

Instead, it reserves blocks of values and stores them in memory.
‍

For example:

• UI Pod 1 reserves sequences 1 – 5

• UI Pod 2 reserves sequences 6 - 10
  ‍
  ‍

Both ranges are unique because they were allocated from the same database sequence.
‍

Each pod now has its own local cache, allowing records to be created without constant database round-trips.
‍

This significantly improves system scalability and performance. However, this is where many reporting and integration issues begin….

Why Sequence Numbers Are Not Chronological

Imagine the following scenario:

Step 1: UI Pod 1 reserves values: 1, 2, 3, 4, 5

Step 2: UI Pod 2 reserves values: 6, 7, 8, 9, 10

Step 3: User with a session in UI Pod 2 creates a Work Order

Step 4: A few moments later, a user with a session in UI Pod 1 creates another Work Order

‍

The result:

If you sort by ID, Work Order UI2 appears newer but in reality, it was created before Work Order UI1.
‍

The sequence values remain unique, but they no longer represent true creation order.

Why This Matters

Many users unknowingly use record IDs as a shortcut to answer questions such as:

• What was the latest Work Order?

• Which Service Request was created most recently?

• What is the newest Inventory Transaction?

• Which Asset was added last?
  ‍

In a multi-pod MAS environment, these questions cannot be reliably answered using the highest sequence value. Doing so can produce inaccurate reports, dashboards, integrations, data migrations and business intelligence outputs.
‍

I’m confident that I’m not the only one who has used some form of the below query in the past to get the latest value:
‍

select * from <table>  
where <column> = ‘<value>’ and   
<table unique id> = (select max(<table unique id>) from <table> where <column> = ‘<value>’) 

Why ROWSTAMP Is Not the Answer

Some, including me, have attempted to use ROWSTAMP as an alternative.
‍

This introduces a different problem since this field also changes whenever a record is updated.
‍

For example:  

If sorted by update date (ROWSTAMP), WO10001 appears newer even though WO10002 was created later.
‍

This makes update-based fields unreliable for identifying the original creation sequence.

What Should You Use Instead?

The correct approach is to use an immutable creation timestamp.  
‍

Examples include:

• Created Date

• Created DateTime

• System-created audit fields

• Other insert-only timestamp columns
  ‍

A useful rule of thumb is:

Use the ID for identity: the sequence-generated identifier uniquely identifies a record.

Use the timestamp for chronology: creation timestamps show when a record was actually inserted.

Use both for stable ordering: when multiple records share the same timestamp granularity, combining timestamp and ID can provide deterministic ordering.

Summary

As MAS Manage deployments increasingly leverage Kubernetes and multiple pods for scalability, assumptions that worked in legacy single-server Maximo environments become less reliable.
‍

Sequence numbers were designed to solve one problem: uniqueness.
‍

They were never intended to act as evidence of creation order.
‍

If your business requirement is to determine what happened most recently, always rely on a true creation timestamp rather than a sequence-generated identifier. Doing so will ensure your reports, integrations, and operational decisions are based on reality rather than the accidental ordering of cached sequence values.

‍