APEX Workflows vs Camunda is one of the most consequential technology decisions facing Oracle-centric enterprises in 2026. APEX Workflows is Oracle’s native, built-in workflow engine — embedded directly inside Oracle Database since APEX 23.2 — that executes business process automation in PL/SQL with zero additional licensing or infrastructure.
Camunda is a standalone, open-source process orchestration platform built on BPMN 2.0 that, since version 8, requires Kubernetes, Elasticsearch, and a separate enterprise licence for production use. The right choice depends on where an organisation’s business logic runs, what skills the team holds, and whether process data must remain within the Oracle Database perimeter.
This comparison matters now because of a specific architectural break. Until 2024, Camunda 7 ran natively on Oracle Database — its process tables could sit alongside application data, share ACID transactions, and be managed by existing DBA teams.
Camunda 8 replaced Oracle with RocksDB as its primary storage engine, fundamentally changing the integration model. Meanwhile, Gartner projects that 80% of enterprises with mature automation practices will consolidate to integrated orchestration platforms by 2029.
For the estimated 430,000+ organisations running Oracle Database worldwide, the question is no longer whether to automate workflows, but where that automation should live.
This article provides a detailed technical and business comparison of both engines, a structured decision framework, and guidance on total cost of ownership — written for CTOs, enterprise architects, and technical decision-makers evaluating workflow automation within Oracle environments.
Camunda 7 to Camunda 8 is not an incremental upgrade. It is a complete re-architecture that removes native Oracle Database compatibility — the very feature that made Camunda attractive to Oracle environments in the first place.
Camunda 7 was Oracle-compatible by design. The engine used a relational database for all persistence — process definitions, runtime state, history, and audit data. Oracle was a first-class supported backend. Camunda tables could live in the same schema as application tables. PL/SQL procedures could interact with process data through standard SQL. DBAs could monitor, back up, and recover workflow state using the same Oracle tooling they used for everything else. The Community Edition was free under Apache 2.0. Camunda 7 Community Edition reaches end of life in October 2025; Enterprise Edition support extends only to April 2030.
Camunda 8 replaces Oracle with RocksDB. The Zeebe engine — Camunda 8’s core — uses RocksDB, an embedded key-value store, as its primary storage. Process execution state never touches Oracle Database.
Historical and query data flows into Elasticsearch or OpenSearch. Starting with version 8.9, Camunda is adding optional RDBMS support for secondary storage (including Oracle), but this only covers visualisation and query data — the execution engine itself remains on RocksDB.
The consequences for Oracle-centric organisations are measurable:
Process data leaves the Oracle security perimeter. In Camunda 7, all workflow data lived inside Oracle, protected by Virtual Private Database (VPD), Fine-Grained Auditing (FGA), Transparent Data Encryption (TDE), and Oracle Data Guard. In Camunda 8, process execution state resides in RocksDB files on Kubernetes pods, historical data sits in Elasticsearch indices, and business data remains in Oracle.
There is no single source of truth, no shared ACID transaction boundary, and three separate security perimeters to manage. For organisations subject to GDPR, PCI-DSS, or SOX, this triples the compliance surface area. For financial institutions navigating DORA and sector-specific compliance requirements, this data bifurcation creates additional audit burden.
Direct PL/SQL integration is technically impossible. Camunda 8 exposes a gRPC API with a REST gateway. There is no native way to invoke this from PL/SQL. Community attempts to load the Zeebe Java client into Oracle via loadjava have failed, and Camunda’s engineering team has confirmed that a Java middleware layer — typically a Spring Boot service — is required as an intermediary. For an Oracle-centric team, this means introducing an entirely new application tier, with its own deployment pipeline and operational overhead, just to trigger a workflow.
The infrastructure footprint multiplies by 4–6x. A production Camunda 8 deployment requires Kubernetes nodes with Helm charts, Zeebe broker pods, an Elasticsearch or OpenSearch cluster, PostgreSQL for Web Modeler and Keycloak, persistent storage volumes, and HTTP/gRPC ingress controllers.
This infrastructure sits alongside — and entirely separate from — existing Oracle RAC, Oracle Enterprise Manager, and Data Guard investments, with zero overlap in tooling or operational procedures. For organisations already managing Oracle Database costs on cloud platforms, adding the Camunda stack represents a significant incremental expense.
Licensing shifted from free to enterprise-only. With Camunda 8.6 (October 2024), all self-managed components moved to the Camunda Licence 1.0, requiring an enterprise agreement for production use. Pricing is not publicly listed and requires contacting Camunda sales.
Oracle APEX Workflows is a native workflow engine built into Oracle Application Express (APEX) that executes entirely inside the Oracle Database. Introduced in APEX 23.2 (October 2023), it enables organisations to model, execute, and monitor business processes using PL/SQL, with zero additional infrastructure, middleware, or licensing costs beyond an existing Oracle Database licence.
Architecture. Workflow metadata, runtime state, instance data, and audit trails are stored in Oracle Database tables. The execution engine runs as Oracle Database scheduler jobs. Activities are implemented in PL/SQL. There is no separate service to deploy, no middleware to maintain, and no additional infrastructure to provision. If an organisation already runs Oracle Database with APEX and ORDS (Oracle REST Data Services), workflows are available immediately.
Supported activity types cover the majority of enterprise workflow scenarios: Execute Code (PL/SQL), Invoke API (PL/SQL procedures or REST data sources), Human Task (approval and action tasks with deadline and escalation policies), Switch (conditional branching), Wait (timer-based pauses), Send Email, Send Push Notification, and Invoke Workflow for sub-workflows (added in APEX 24.2).
Release trajectory shows rapid maturation. APEX 23.2 (October 2023) shipped the Visual Workflow Designer and Runtime Engine. APEX 24.1 (June 2024) added the Workflow Dashboard and runtime Workflow Diagram region. APEX 24.2 (early 2025) introduced sub-workflows, CLOB variable support, resume-at-any-activity capability, and runtime instance export. Oracle has made workflows a strategic priority, delivering substantial new functionality in every release. Pretius has documented the practical challenges and solutions for APEX Workflow version management and bug fixes based on real-world project experience.
Licensing cost is zero. APEX and APEX Workflows are included with all editions of Oracle Database — Enterprise Edition, Standard Edition 2, Express Edition (free), and Autonomous Database on Oracle Cloud Infrastructure. There is no additional licence, no per-user fee, and no per-workflow charge. Oracle APEX Service on OCI starts at approximately $122/month; an Always Free tier is also available.
The learning curve for existing Oracle teams is low. The Visual Workflow Designer mirrors the familiar APEX Page Designer interface. The APEX_WORKFLOW PL/SQL API provides full programmatic control — start, suspend, resume, terminate, retry, and variable manipulation. Runtime data is accessible through standard SQL views (APEX_WORKFLOWS, APEX_TASKS, APEX_WORKFLOW_VARIABLES), meaning existing Oracle reporting, auditing, and analytics tooling works without modification.
The deliberate absence of BPMN 2.0 is a design choice, not a limitation. Oracle’s APEX engineering team stated that BPMN 2.0 is comprehensive but complex, and typically requires dedicated BPM methodology training. APEX Workflows use a simpler, proprietary model that is sufficient for the application-centric workflow patterns (approvals, task routing, case management, operational processes) that represent 80–90% of enterprise workflow use cases. For organisations that require full BPMN 2.0 compliance, the open-source Flows for APEX project (with a commercial Enterprise Edition from Flowquest) provides BPMN 2.0 modelling and execution within the Oracle/APEX ecosystem.
The following comparison addresses the twelve dimensions most relevant to decision-makers evaluating workflow engines for Oracle-centric environments. Each dimension includes a direct recommendation.
Integration with Oracle Database. APEX Workflows run inside the database. Workflow logic executes in PL/SQL and shares ACID transactions with application data. Camunda 8 runs outside the database and requires a Java middleware layer for every interaction with Oracle. Recommendation: APEX Workflows for Oracle-native environments; Camunda only if Oracle is a secondary data store.
Total cost of ownership (5-year estimate). For an organisation already running Oracle Database, APEX Workflows add zero infrastructure and zero licensing cost — the only investment is developer time.
Camunda 8 adds Kubernetes cluster costs, Elasticsearch or OpenSearch licensing, PostgreSQL hosting, Keycloak infrastructure, enterprise licence fees (required for production since October 2024, pricing not public), and ongoing operational costs for a technology stack entirely separate from Oracle.
Industry benchmarks suggest Camunda 8 TCO for a mid-size deployment ranges from $150,000 to $500,000+ annually, depending on scale and support tier. Recommendation: APEX Workflows for cost-sensitive Oracle shops; Camunda for organisations with existing Kubernetes budgets.
Developer skills required. APEX Workflows require PL/SQL, SQL, and APEX — skills that already exist in Oracle development teams. Camunda requires Java or JavaScript for Job Workers, Kubernetes and Helm for deployment,
Elasticsearch for operational monitoring, gRPC for engine communication, and FEEL (Friendly Enough Expression Language) for in-process decision logic. G2 reviews consistently describe Camunda’s learning curve as steep.
Forrester reports that 89% of developers have spent time on low-code platforms, supporting the trend towards embedded, low-code workflow tools. Recommendation: APEX Workflows where the existing team is Oracle-skilled; Camunda where strong Java/K8s expertise already exists.
BPMN 2.0 support. Camunda provides what is widely recognised as the most complete and faithful BPMN 2.0 implementation available, with full DMN 1.3 support. Process diagrams are directly executable. APEX Workflows do not support BPMN 2.0 — they use a simpler, proprietary model. Recommendation: Camunda where BPMN 2.0 is a contractual, regulatory, or interoperability requirement. APEX Workflows where the actual process patterns (approvals, routing, case management) do not require formal BPMN notation.
Data residency and compliance. APEX Workflows keep all process data inside Oracle Database — subject to the same encryption, access controls, audit policies, and geographic constraints as every other regulated data asset. Camunda 8 distributes process data across RocksDB (execution state), Elasticsearch (historical data), and PostgreSQL (identity management), each with a separate security model. Recommendation: APEX Workflows for regulated industries (financial services, healthcare, government) where data residency within Oracle is mandatory.
Scalability model. Camunda 8 is designed for horizontal scalability — Zeebe brokers can be partitioned across nodes, and throughput scales linearly. APEX Workflows scale vertically with Oracle Database, leveraging Oracle RAC, Exadata, and Autonomous Database elasticity. Recommendation: Camunda for internet-scale, millions-of-instances-per-day orchestration across distributed microservices. APEX Workflows for application-centric workflows within Oracle environments, which typically handle thousands to tens of thousands of instances per day.
Security model. APEX Workflows inherit Oracle Database security — VPD, FGA, TDE, Oracle Label Security, Oracle Database Vault, and network encryption — automatically and without configuration. Camunda 8 requires separately configuring Keycloak (OIDC), TLS certificates, Kubernetes network policies, and Elasticsearch security. Recommendation: APEX Workflows where Oracle security infrastructure must be the single control plane.
Audit trail and observability. APEX Workflows store all audit data in Oracle Database tables, queryable via standard SQL and accessible through existing Oracle reporting tools (Oracle Analytics, APEX Interactive Reports, third-party BI). Camunda 8 stores audit data in Elasticsearch indices, accessible through Operate and Optimize, but not through Oracle-native tooling. Recommendation: APEX Workflows where audit data must be co-located with business data and accessible through existing Oracle analytics infrastructure.
Human task management. APEX Workflows provide a built-in Unified Task List that aggregates tasks across multiple APEX applications. Camunda 8 provides Tasklist as a separate component. Both support task assignment, delegation, deadlines, and escalation. Recommendation: Comparable; APEX Workflows have an edge when tasks must integrate with existing APEX application UIs.
Sub-process and orchestration complexity. APEX 24.2 introduced Invoke Workflow for sub-workflows. Camunda supports call activities, event sub-processes, message correlation, signal events, and complex multi-instance patterns. Recommendation: Camunda for complex orchestration patterns requiring event-driven coordination across dozens of services. APEX Workflows for structured, sequential-to-moderately-complex business processes.
Maintenance burden. APEX Workflows upgrade with the APEX platform — no separate patch cycles, version compatibility matrices, or middleware upgrade procedures. Camunda 8 operates on an 18-month support window per version, requiring separate Kubernetes rolling updates, Elasticsearch index migrations, and cross-component compatibility verification. Recommendation: APEX Workflows for organisations that want workflow maintenance handled by existing Oracle DBA operations.
Cross-system orchestration. Camunda provides native connectors, a marketplace of pre-built integrations, and is designed for polyglot, microservices orchestration. APEX Workflows can call external services via REST Data Sources but are primarily designed for Oracle-centric processes. Recommendation: Camunda for orchestrating across ERP, CRM, cloud services, and multiple non-Oracle databases. APEX Workflows where Oracle is the centre of gravity and external integrations are supplementary.
APEX Workflows is the right workflow engine for Oracle environments when the following conditions are true:
Oracle Database is the centre of gravity. The organisation’s core data, business logic, and applications run on Oracle Database and Oracle APEX. Workflows are an extension of existing application logic, not a separate orchestration layer. This describes the majority of Oracle customers — including banking, insurance, and government organisations that have built decades of business logic in PL/SQL.
The team holds Oracle skills. PL/SQL developers, Oracle DBAs, and APEX builders are the available talent. A senior APEX developer can build production workflows within days, not months. Introducing Java, Kubernetes, and Elasticsearch represents a multi-quarter skills investment that is not justified by the workflow requirements alone.
Process data must stay inside Oracle. Regulatory, compliance, or architectural requirements dictate that workflow state and audit trails reside within the Oracle Database perimeter. APEX Workflows satisfy this by default — no additional data residency configuration is needed.
Cost optimisation is a priority. APEX Workflows deliver workflow automation at zero incremental licensing or infrastructure cost. Forrester research indicates that 82% of organisations still route tasks manually via paper and email spreadsheets — suggesting that the barrier to workflow adoption is often cost and complexity, not capability. APEX Workflows remove both barriers.
The workflow patterns are application-centric. Approval chains, document routing, task management, case management, multi-step business processes with human interaction, and GL journal approvals integrated with Oracle ERP — these are the patterns APEX Workflows are designed for. Real-world deployments include financial institutions processing regulatory disclosures, universities managing energy efficiency approvals, and enterprises automating Oracle Fusion Cloud ERP journal workflows.
Camunda is the right workflow engine when the following conditions are true:
The architecture is polyglot and distributed. Oracle is one of many data stores in a microservices environment. Workflows must orchestrate across Kafka, REST APIs, cloud services, and multiple databases. The workflow engine must be technology-neutral. Camunda serves over 700 enterprise customers — including Goldman Sachs, Atlassian, and Deutsche Telekom — in exactly this architectural pattern.
BPMN 2.0 is a hard, verified requirement. The organisation has invested in formal BPM methodology, requires standardised process notation for cross-organisational collaboration, or needs vendor portability for process definitions. Camunda was named a Visionary in Gartner’s first Magic Quadrant for Business Orchestration and Automation Technologies (BOAT).
Horizontal scalability is non-negotiable. Workflow throughput requirements are in the millions of instances per day, spanning distributed systems. Zeebe’s partitioned broker architecture scales linearly with additional nodes.
Java and Kubernetes expertise already exist. The team has strong Java, Kubernetes, and DevOps capabilities. The infrastructure is already containerised. Adding Camunda to an existing Kubernetes cluster is operationally straightforward.
Cross-system orchestration is the primary use case. The workflow engine must coordinate across ERP, CRM, external partner APIs, messaging platforms, and cloud services — with Oracle being one participant among many, not the centre of gravity. For organisations evaluating alternatives to Camunda more broadly — including Activiti and other BPM platforms — the comparison should include the low-code workflow path that APEX Workflows represent.
Before committing to either workflow engine, the following questions should have clear, documented answers:
The choice between APEX Workflows and Camunda is not primarily a feature comparison. It is an architectural decision about where workflow logic should live in relation to the rest of the Oracle estate.
APEX Workflows keep everything inside the database — logic, state, data, security, and operations. This is the right model for organisations where Oracle is the foundation, where data governance is paramount, and where the goal is to automate business processes without introducing new infrastructure, new skills gaps, or new compliance surface area.
Camunda is the right model for organisations operating distributed, polyglot architectures where Oracle is one component among many, and where the workflow engine must serve as a neutral orchestration layer across diverse technologies.
For Oracle-centric organisations that chose Camunda 7 specifically because it integrated with their database — and now face a forced migration to a fundamentally different architecture in Camunda 8 — the emergence of APEX Workflows offers a genuinely native alternative that did not exist two years ago.
The architecture of the workflow engine should match the architecture of the environment it serves.
Pretius has been building enterprise applications on Oracle technology for over 20 years. The team includes 300+ specialists and 7 Oracle ACEs with deep expertise in both Oracle APEX Workflows and Camunda migration scenarios. Whether you are evaluating APEX Workflows for the first time, migrating from Camunda 7, or deciding between native and standalone workflow engines — talk to us.
Can APEX Workflows replace Camunda for Oracle-centric organisations? APEX Workflows can replace Camunda for application-centric workflow patterns — approvals, document routing, task management, case management, and operational business processes — in Oracle-centric environments. They cannot replace Camunda for complex, cross-system orchestration across polyglot microservices architectures or where BPMN 2.0 standard compliance is contractually required.
Does Oracle APEX support BPMN 2.0? Oracle APEX Workflows do not use BPMN 2.0. They use a simpler, proprietary workflow model designed for application-centric processes. For organisations requiring BPMN 2.0 within an Oracle/APEX environment, the open-source Flows for APEX project (with a commercial Enterprise Edition from Flowquest) provides BPMN 2.0 modelling and execution.
Is Camunda 8 compatible with Oracle Database? Camunda 8’s primary execution engine (Zeebe) uses RocksDB, not Oracle Database. Starting with version 8.9 (2026), Camunda is adding optional Oracle support for secondary storage (query and visualisation data only). The execution engine cannot run on Oracle. Direct PL/SQL integration is not possible — a Java middleware layer is required.
What does Oracle APEX Workflows cost? APEX Workflows are included at no additional cost with all editions of Oracle Database — Enterprise Edition, Standard Edition 2, Express Edition (free), and Autonomous Database. There are no per-user, per-application, or per-workflow fees. The only requirement is a properly licensed Oracle Database.
What is the learning curve for APEX Workflows vs Camunda? For existing Oracle/APEX teams, APEX Workflows have a low learning curve — the Visual Workflow Designer mirrors APEX Page Designer, and all logic is written in PL/SQL. Camunda requires proficiency in Java or JavaScript, Kubernetes, Elasticsearch, gRPC, and FEEL expression language, which G2 reviewers describe as a steep learning curve.
Which workflow engine is better for regulated industries like banking and insurance? For Oracle-centric financial institutions, APEX Workflows offer significant compliance advantages: all process data remains inside Oracle Database, protected by existing VPD, FGA, TDE, and Data Guard controls, with audit trails queryable via standard SQL. Camunda 8 distributes data across three separate storage systems, each requiring independent compliance measures. Pretius has delivered Oracle APEX solutions for banking clients including Santander, with regulatory compliance enforced at the database level.
