Value too large for column "CAMUNDA_PROD"."ACT_HI_VARINST"."TEXT_"

We’re using the Camunda engine 7.9.0 with an Oracle database 19c.
In the database, the field “ACT_HI_VARINST.TEXT_” is defined as NVARCHAR2(2000).
Can this field be converted to a CLOB, or does this have any side effects?

@rlehnert You’re encountering the “Value too large for column” error because Camunda 7.9.0 tries to store a variable’s value (typically a String or serialized object) in the ACT_HI_VARINST.TEXT_ column, which is limited to 2000 characters (bytes) in Oracle due to NVARCHAR2(2000).

:mag: Root Cause:

In Camunda 7.9.0:

  • If a variable value is short (<= 2000 characters), it is stored in the TEXT_ column.
  • If it exceeds the size, it should be stored in the BYTEARRAY_ column via the ACT_GE_BYTEARRAY table.
  • However, Camunda only does this if the variable is declared as a serializable Java object or a byte array, not for long strings.

Recommended Solutions

Option 1: Upgrade Camunda Version

Camunda 7.15+ has much better handling of long string variables. It automatically stores long strings in the ACT_GE_BYTEARRAY table.

  • Advantage: No DB schema changes required.

  • How:

    • Upgrade to at least Camunda 7.15 (7.19 is better).
    • Re-test process definitions that store large string variables.
    • Optionally, enable the StringValueSerializer fallback mechanism (available in newer versions).

Option 2: Store Large Variables as Serialized Objects

If you cannot upgrade, you can explicitly store long values in a way Camunda uses the BYTEARRAY_ mechanism:

runtimeService.setVariable(processInstanceId,
    "longStringVar",
    Variables.serializedObjectValue(largeString)
        .serializationDataFormat(SerializationDataFormats.JAVA)
        .create());
  • Pros: Bypasses the TEXT_ column entirely.
  • Cons: Stored as a serialized object, not plain text.

Option 3: Manual Workaround Using CLOB (Not Recommended)

You can alter the table to change the column TEXT_ from NVARCHAR2(2000) to CLOB, but Camunda does not officially support this, and it may break assumptions in:

  • Query performance
  • Compatibility with Camunda APIs
  • Variable deserialization

If you still want to go ahead:

ALTER TABLE CAMUNDA_PROD.ACT_HI_VARINST MODIFY TEXT_ CLOB;

:warning: Side Effects:

  • CLOB access requires different handling in Java JDBC (stream-based).
  • It may break Camunda internal SQL queries that expect TEXT_ to be NVARCHAR2.
  • Indexes on this column (if any) will be invalidated.

Best Practice (Short-Term Fix)

If upgrade isn’t possible yet:

  • Avoid setting long strings as process variables directly.

  • Instead:

    • Store large data in external storage (e.g., DB or S3).
    • Pass a reference (ID or URL) as a short string variable.

Hello,

Are you Upgrade to at least Camunda 7.15 ?

Best Regard,
Angela

@aravindhrs,
thank you for the detailed explanation.
I will discuss a migration to 7.19 with my colleagues in IT.
This seems to be the most sensible approach.

Best regards
Rolf

This is not true IMO. Strings are still saved as strings. Hence, if you have a string value that is longer than 2000 characters you should store it in a wrapper object. Objects are always stored as blobs so there is no limitation on the size.

Camanda 7.9 is ancient. Why do you still use this version (asking just out of interest).