Skip to content

overview.md

Latest commit

 

History

History
81 lines (52 loc) · 4.51 KB

overview.md

File metadata and controls

81 lines (52 loc) · 4.51 KB
id overview
title Overview
description Learn how Camunda uses document and relational databases for secondary storage, including supported options, limitations, and where to find configuration details.

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

App RDBMS Non-SQL
Orchestration Cluster Yes Yes
Optimize No Yes
Web Modeler Yes No
Management Identity Yes No

Use this matrix as a compatibility summary for the main Camunda components and their supported database backends.

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 the Orchestration Cluster API, Operate, Tasklist, and Admin 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.

Related database topics

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. :::