Skip to main content
Version: 8.9 (unreleased)

Overview

Camunda applications depend on a secondary storage backend to read workflow and decision data exported from the Zeebe engine.

This storage layer can use either document databases or relational databases (RDBMS), depending on your requirements.

For an architectural explanation of how secondary storage fits into Camunda 8, see the
secondary storage overview.

Document databases​

Camunda supports document-oriented backends such as Elasticsearch and OpenSearch.

These systems are optimized for high-volume ingestion and flexible search queries, and they remain the default choice for most production deployments.

Related documentation:

Relational databases (RDBMS)​

Camunda also supports several relational databases for secondary storage, enabling Operate, Tasklist, Identity, and REST APIs to run without Elasticsearch or OpenSearch.

A full list of supported vendors and versions is published in the RDBMS support policy.

For configuration details in Helm deployments, see the RDBMS configuration guide.

RDBMS behavior and limitations​

When using an RDBMS as secondary storage, keep the following limitations in mind:

  • ID size limits: Identifiers such as process definition IDs, decision IDs, and usernames are limited to 255 characters. Storing values significantly longer may result in errors. (This behavior will change once this issue is complete.)

  • Variable comparisons: For String and JSON variables, comparison operators (equals, notEquals, in, notIn) only consider the first 8191 characters (or 4000 characters with Oracle). LIKE comparisons are not affected.

  • Sorting may differ by vendor: Because collation behavior varies across database vendors, results sorted by string fields may differ between systems.

Working with variables​

When retrieving variables through the Orchestration Cluster REST API, the following comparison operators only apply to the first 4000 characters of large String or JSON variables:

  • equals
  • notEquals
  • in
  • notIn

This ensures consistent performance on large datasets. For details, see the get variable specification.

These pages provide deeper detail for operators, DBAs, and administrators:

note

For guidance on coordinating backups between Zeebe (primary storage) and your configured secondary storage backend—whether Elasticsearch, OpenSearch, or an RDBMS—see the backup and restore overview.