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 actualizado.
‍

Por ejemplo:  

Si se ordena por fecha de actualización (ROWSTAMP), WO10001 parece más reciente aunque WO10002 se creó después.
‍

Esto hace que los campos basados en actualizaciones no sean fiables para identificar la secuencia de creación original.

¿Qué debería utilizar en su lugar?

El enfoque correcto es utilizar una marca de tiempo de creación inmutable.  
‍

Algunos ejemplos son:

• Fecha de creación

• Fecha y hora de creación

• Campos de auditoría creados por el sistema

• Otras columnas de marca de tiempo de solo inserción
  ‍

Una regla general útil es:

Use el ID para la identidad: el identificador generado por secuencia identifica de forma única un registro.

Use la marca de tiempo para la cronología: las marcas de tiempo de creación muestran cuándo se insertó realmente un registro.

Use ambos para un orden estable: cuando varios registros comparten la misma granularidad de marca de tiempo, combinar la marca de tiempo y el ID puede proporcionar un orden determinista.

Resumen

A medida que las implementaciones de MAS Manage aprovechan cada vez más Kubernetes y múltiples pods para la escalabilidad, las suposiciones que funcionaban en los entornos heredados de Maximo de servidor único se vuelven menos fiables.
‍

Los números de secuencia fueron diseñados para resolver un problema: unicidad.
‍

Nunca tuvieron la intención de actuar como prueba de orden de creación.
‍

Si su necesidad de negocio es determinar qué sucedió más recientemente, confíe siempre en una marca de tiempo de creación real en lugar de un identificador generado por secuencia. Hacerlo garantizará que sus informes, integraciones y decisiones operativas se basen en la realidad y no en el orden accidental de los valores de secuencia almacenados en caché.

‍