Secondary storage
Camunda uses a layered storage model that separates workflow execution data from data used by web applications and APIs.
About secondary storage
Secondary storage is one of the two complementary layers in Camunda’s data model:
| Layer | Purpose | Technologies you can use |
|---|---|---|
| Primary storage | Persists real-time workflow execution state managed by Zeebe. | RocksDB (embedded in Zeebe) |
| Secondary storage | Stores workflow, decision, and task data for querying, visualization, and API access. | Elasticsearch/OpenSearch, RDBMS (including H2 and external relational databases) |
Secondary storage is not a duplicate of primary data. It represents exported workflow and decision data optimized for querying and visualization.
Supported storage options
Camunda supports multiple secondary storage backends.
For the latest list of supported database versions, see the
RDBMS version support policy.
| Database type | Availability | Use case |
|---|---|---|
| Elasticsearch/OpenSearch | General availability | Secondary storage for indexing, search, and analytics. |
| RDBMS | 8.9-alpha1+ | Secondary storage for relational database deployments. See the RDBMS support policy for supported vendors and versions. |
Camunda 8 supports both Amazon OpenSearch and the open-source OpenSearch distribution.
Starting in 8.9-alpha3, Camunda 8 Run and default lightweight installs use H2 as the default secondary storage. Elasticsearch remains supported and is bundled for backward compatibility; OpenSearch is supported for Self‑Managed deployments but is not bundled in Camunda 8 Run. Enable the backend you need explicitly when required.
Data flow
The following diagram shows how secondary storage fits into the Camunda data flow.
- The Zeebe broker executes workflow instances and stores state in primary storage.
- The exporter, part of Zeebe, streams workflow and task data to secondary storage.
- Applications such as Operate, Tasklist, and the REST API read data from secondary storage.
Choosing a secondary storage backend
Camunda supports multiple secondary storage backends, and the right choice depends on your workload and operational constraints.
For guidance on supported vendors, versions, and configuration, see:
The documentation is intentionally descriptive rather than prescriptive. Use benchmarking and sizing based on your own workload to choose the secondary storage backend that best meets your requirements.
Learn how to configure secondary storage in Self-Managed environments using Helm, Docker, or manual deployment.
Although you should use secondary storage in nearly all production environments, you can choose to disable secondary storage in limited scenarios, such as lightweight development environments, specialized technical use cases, or resource-constrained deployments. See run without secondary storage.
Manage secondary storage
Learn about best practices for data management, backups, and monitoring to ensure data integrity and performance.
Effective secondary storage management ensures stability, scalability, and data integrity across your Camunda environment. By following Camunda best practices, you can avoid data corruption, maintain compliance, and ensure your orchestration environment remains performant and reliable.