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 a document-store backend or a relational database (RDBMS), depending on your requirements.

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

App database support​

AppRDBMSNon-SQL
Orchestration ClusterYesYes
OptimizeNoYes
Web ModelerYesNo
Management IdentityYesNo

Use this matrix as a quick decision aid when planning your deployment topology.

Document-store backends​

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

These systems are optimized for high-volume ingestion and flexible search queries.

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.

RDBMS and document-store backends are both valid secondary storage options. Select based on your workload, operational model, and platform standards.

A full list of supported vendors and versions, JDBC driver information, and component compatibility 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.