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. Both document-store and RDBMS backends are valid choices in Self-Managed deployments. Support maturity can vary by product area and version (for example, the Orchestration Cluster API, Operate, Tasklist, Admin, or Optimize), so confirm current compatibility details before choosing a backend. For supported database versions, see the RDBMS version support policy.
| 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.
How secondary storage works
The Zeebe Broker executes workflow instances and stores state in primary storage. Exporters running as part of Zeebe write orchestration data to the configured secondary storage backend and can write to multiple targets when needed. Operate, Tasklist, and Admin use the Orchestration Cluster API, which reads from the configured secondary storage backend.
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:
- Secondary storage configuration
- RDBMS configuration
- RDBMS version support policy
- RDBMS benchmark results
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.
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.
🗃️ Configure
1 item
Manage
Follow best practices to maintain, back up, and monitor your secondary storage data to ensure reliability and performance.
🗃️ Databases
2 items