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. | Document-store or RDBMS |
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.
Both document-store and RDBMS backends are valid secondary storage choices in Self-Managed deployments. Support maturity can vary by product area and version (for example, Orchestration Cluster APIs, Operate, Tasklist, Identity, or Optimize), so confirm current compatibility details before choosing a backend.
| Database type | Availability | Use case |
|---|---|---|
| Document-store (ES/OS) | General availability | Secondary storage for indexing, search, and analytics. |
| RDBMS | 8.9+ | 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, Camunda 8 Run and default lightweight installs use H2 as the default secondary storage. Elasticsearch remains a supported alternative in Camunda 8 Run. OpenSearch and RDBMS-based secondary storage are supported in Self-Managed deployments. Enable the backend you need explicitly when required.
H2 is a convenience default for local development, testing, and evaluation. It is not a production reference architecture and is not a valid backend for multi-broker Helm clusters.
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.
- Orchestration Cluster applications and APIs (for example, Operate, Tasklist, Identity, and the Orchestration Cluster 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.