The database schema of the process engine consists of multiple tables. The table names all start with ACT. The second part is a two-character identification of the use case of the table. This use case will also roughly match the service API.
REstands for repository. Tables with this prefix contain ‘static’ information such as process definitions and process resources (images, rules, etc.).
RUstands for runtime. These are the runtime tables that contain the runtime data of process instances, user tasks, variables, jobs, etc. The engine only stores the runtime data during process instance execution and removes the records when a process instance ends. This keeps the runtime tables small and fast.
IDstands for identity. These tables contain identity information such as users, groups, etc.
HIstands for history. These are the tables that contain historical data such as past process instances, variables, tasks, etc.
ACT_GE_*: General data, which is used in various use cases.
The main tables of the process engines are the entities of process definitions, executions, tasks, variables and event subscriptions. Their relationship is shown in the following UML model.
Process Definitions (
ACT_RE_PROCDEF table contains all deployed process definitions. It
includes information like the version details, the resource name or the
ACT_RU_EXECUTION table contains all current executions. It includes
information like the process definition, parent execution, business key, the
current activity and different metadata about the state of the execution.
ACT_RU_TASK table contains all open tasks of all running process
instances. It includes information like the corresponding process instance,
execution and also metadata such as creation time, assignee or due date.
ACT_RU_VARIABLE table contains all currently set process or task
variables. It includes the names, types and values of the variables and
information about the corresponding process instance or task.
Event Subscriptions (
ACT_RU_EVENT_SUBSCR table contains all currently existing event
subscriptions. It includes the type, name and configuration of the expected
event along with information about the corresponding process instance and
Schema Log (
ACT_GE_SCHEMA_LOG table contains a history of the database
schema version. New entries to the table are written when changes to
the database schema are made. On database creation the initial entry
is added. Every update script adds a new entry containing an
version the database was updated to and the date and time
timestamp) of the update.
To retrieve entries from the schema log, the SchemaLogQuery-API can be used:
List<SchemaLogEntry> entries = managementService.createSchemaLogQuery().list();
Metrics Log (ACT_RU_METER_LOG)
ACT_RU_METER_LOG table contains a collection of runtime metrics that can help draw conclusions about usage, load
and performance of the Camunda Platform. Metrics are reported as numbers in the Java
long range and count the occurrence of
specific events. Please find detailed information about how metrics are collected in the Metrics User Guide.
The default configuration of the MetricsReporter will create one row per metric in
ACT_RU_METER_LOG every 15 minutes.
If you are an enterprise customer, your license agreement might require you to report some metrics annually. Please store
executed-decision-elements metrics for at least 18 months until they were reported.
Task Metrics Log (ACT_RU_TASK_METER_LOG)
ACT_RU_TASK_METER_LOG table contains a collection of task related metrics that can help draw conclusions about usage, load
and performance of the BPM platform. Task metrics contain a pseudonymized and fixed-length value of task assignees and their time of appearance. Please find detailed information about how task metrics are collected in the Metrics User Guide.
Every assignment of a task to an assignee will create one row in
If you are an enterprise customer, your license agreement might require you to report some metrics annually. Please store task metrics for at least 18 months until they were reported.
Entity Relationship Diagrams
The database is not part of the public API. The database schema may change for MINOR and MAJOR version updates.
Please note: The following diagrams are based on the MySQL database schema. For other databases the diagram may be slightly different.
The following Entity Relationship Diagrams visualize the database tables and their explicit foreign key constraints, grouped by Engine with focus on BPMN, Engine with focus on DMN, Engine with focus on CMMN, the Engine History and the Identity. Please note that the diagrams do not visualize implicit connections between the tables.
To allow different configurations and to keep the tables more flexible, the history tables contain no foreign key constraints.