Running Flowable on Oracle, SQL Server or DB2: what changes for your team
Flowable can run on Oracle, Microsoft SQL Server and DB2, so a Java team that already standardizes on one of these databases can usually keep that standard for its process, case and decision engines. The Flowable configuration docs list all three among the supported database types, alongside H2, MySQL and PostgreSQL. The database still changes four things: the JDBC driver you package, how the schema is created and upgraded, how the engine handles tenant identifiers on Oracle, and how bulk inserts behave on DB2. The engines are licensed under Apache 2.0, so the database decision is a technical and operating one that your team owns.
This page is for teams where enterprise policy has already settled the database. Typical cases include a DBA group that owns every schema and runs only the DDL scripts it has reviewed, a backup and recovery standard built around one vendor's tooling, or a support contract that already covers the database. In these cases the questions are operational: which driver version your DBA approves, whether the create and upgrade scripts for your database match the engine version you plan to run, and who owns connection pool sizing for the async executor. Driver and database version support is set by the vendors and the project, so confirm it against the exact engine version you deploy rather than relying on this summary.
Before you commit, run a short proof on a non-production copy of your database. Confirm that the driver you plan to package loads with the engine's JDBC settings, and that the schema scripts run under the account your DBA grants. If you use tenant identifiers, test the empty string tenant handling on Oracle directly, since it affects how records are filtered. On SQL Server, confirm how your index design interacts with nvarchar columns in the release you choose. On DB2, exercise the bulk insert path with history volumes close to what production will generate, because that is where you should look for bulk insert exceptions. Check each step against the Flowable configuration documentation.
How Oracle, SQL Server and DB2 differ inside Flowable
The main difference to plan for on Oracle is how empty strings are stored. Oracle treats an empty string as NULL, so any logic that tells "no value" apart from "empty value" can behave differently than it does on other databases. In Flowable, this matters most where tenant identifiers separate data, because tenant matching depends on the stored value being found exactly. Teams that use blank tenant IDs to mean a default tenant should confirm how the engine behaves on Oracle before they copy that convention.
- Who is affected: multi-tenant deployments, and any custom query, delegate or report that filters on a tenant value, especially a blank one.
- What to test: deploy a model and start instances with no tenant, with an empty tenant and with a named tenant, then query each set through the Java API and the REST API.
- Custom SQL: review your own mapped statements, views and reporting queries for null checks written with the assumption that empty strings are stored as values.
- Data migration: if you move data from another database, check tenant columns for empty strings, because Oracle stores them as NULL.
Confirm the exact tenant behavior for your engine version in the Flowable configuration docs before you set a tenant convention.
SQL Server differs mainly in how indexed text columns are sized and indexed. Flowable's schema stores many identifiers and text values in Unicode columns, and index behavior on those columns affects lookup speed and the index key size the database allows. The Flowable release notes describe indexing improvements for nvarchar columns on SQL Server. These changes matter most for installations that created the schema on an earlier engine version and then upgraded, because an upgrade may or may not add new index definitions to tables that already exist.
- Who is affected: teams upgrading an existing SQL Server schema, and teams with large history tables where queries on text keys run frequently.
- What to check: compare the index definitions in the upgraded schema with the definitions the new engine version expects, and ask Flowable which changes your upgrade path applies to existing tables.
- Query plans: capture execution plans for process instance and task queries before and after the upgrade, using data volumes close to production.
- Collation and column length: record the database collation and any custom columns you added, since both affect index key size.
Before you upgrade, ask Flowable which index changes apply to your engine version and whether they run against tables that already contain data.
DB2 differs in how batched writes behave. Flowable groups some inserts into batches to improve throughput, particularly during deployments that create many definitions and during periods of heavy history writing. The Flowable release notes record bulk insert exceptions on DB2. An exception during a batch can fail the transaction that contains it, so the practical risk is a failed deployment or a job that needs a retry, rather than an unnoticed gap in data. Teams with heavy write loads or large deployment bundles are the most exposed.
- Who is affected: teams with high write volume, large numbers of process, case or decision definitions per deployment, or frequent history writes.
- Deployment test: deploy a realistic bundle of BPMN, CMMN and DMN files in one batch in a test environment, and confirm that the transaction completes and every definition is visible afterward.
- Job behavior: run the async executor under representative load and confirm that failed jobs retry as expected and leave no partial state behind.
- Diagnostics: turn on verbose persistence logging in the test environment so that exceptions and the statements behind them are visible when a batch fails.
Confirm the affected statements and the fixed release for your engine version in the Flowable release notes, and set any batch sizes only after testing them on DB2.
Database options and when each fits
This table compares the database types the Flowable configuration docs list (Oracle, Microsoft SQL Server, DB2, PostgreSQL, MySQL and H2) on the factors that usually decide the choice: existing DBA skills, licensing and standards, driver choice, tenant handling and bulk insert behavior. Use each row to start a conversation with your DBA before deciding, and confirm driver versions with them in every case. The main takeaway is that the database your team already runs and can support matters most, while Oracle, SQL Server and DB2 each need specific tests before go-live.
| Database | When it fits | What to check before choosing |
|---|---|---|
| Oracle | Your organization already runs Oracle, and your DBAs manage it under existing licensing. | Empty string tenant handling differs on Oracle, so test tenant-scoped data early. |
| Microsoft SQL Server | Your DBAs already run SQL Server and standardize on its backup and monitoring tools. | Review nvarchar index behavior on your SQL Server version and confirm the JDBC driver with your DBA. |
| DB2 | Your estate already runs DB2 at a level your DBAs support. | Test bulk insert paths early, since DB2 raises exceptions there that other types do not. |
| PostgreSQL | You want an open-source database and your DBAs already operate it. | Confirm schema creation and connection pool settings in the PostgreSQL topic for this pillar. |
| MySQL | Your platform team already runs MySQL at a version that Flowable supports. | Versions below 5.6.4 lack millisecond precision, so confirm your version before choosing. |
| H2 | Quick starts, demos and automated tests on a developer machine. | Confirm with your team and security reviewers before any production use. |
Setup sequence for Flowable on Oracle, SQL Server or DB2
This sequence takes a Flowable engine from a confirmed database choice to a running Spring Boot application that reads and writes its tables on Oracle, Microsoft SQL Server or DB2. Each step closes with a check, so a fault surfaces at the step that caused it, before any process models are deployed.
Confirm database type and engine version
The platform team and the DBA confirm that the database product and version appear in the supported database types listed in the Flowable configuration docs, and that the engine version you plan to run supports that database. Agree the character set and collation before installation, because they affect indexing and tenant queries later. Note that Flowable 8.0.0 moved to Spring Boot 4 with no backward compatibility for Spring Boot 3, so the application baseline must match. Check: a written record from the DBA naming the product, version and collation, matched against the supported list. Hold the sequence if any item does not match.
Add the JDBC driver
The developer adds the JDBC driver for the chosen database to the application build, taking the driver from your approved artifact repository and pinning its version. Keep the driver out of any shared library that other services use, so that a driver change does not affect unrelated applications. Confirm the vendor's licensing and redistribution terms for the driver with your legal or procurement team before it enters a production image. Check: the application starts, the driver class loads in the startup log, and a test connection runs a simple query against the target database.
Set datasource and schema properties
The developer sets the datasource URL, username and password in the Spring Boot configuration, with the password read from your secret store rather than a file in the repository. Configure the connection pool and set the Flowable database type so the engine uses the correct dialect. In environments where the DBA owns all DDL, turn off automatic schema creation and updates. Confirm the exact property names against the Spring Boot docs for your engine version. Check: start the application against an empty test schema and confirm the log names the expected database type, with no connection or dialect errors.
Apply schema scripts through the DBA
The DBA creates the Flowable tables by running the create scripts for the target database, covering the engine and history table sets you enabled. A non-production instance can generate reference DDL first, so the DBA reviews what the engine expects before anything reaches production. Store the approved scripts in version control with the release, and use the matching upgrade scripts for later versions. Check: compare the table list in the target schema with the reference script for the same engine set, and record the DBA's sign-off with the script version used.
Verify async executor lock acquisition
Start two application instances against the same schema and deploy a test process with a timer and an async task. The async executor on each node acquires job locks using lock owners and lock expiration times stored in the database. Stop the node holding a job while it waits, then confirm another node picks the job up after the lock expires. On Oracle and SQL Server, watch the database logs for lock waits or deadlocks during this test. Check: the job completes once, and the lock columns show the owner change in the expected order.
Run tenant and bulk insert tests
Run the database-specific test cases before any production data arrives. On Oracle, create and query instances with an empty string tenant identifier and confirm that filters return the instances you expect, because Oracle's handling of empty strings can differ from other databases. On Microsoft SQL Server, check query plans for the indexes on nvarchar columns after a realistic data load. On DB2, run a bulk insert workload that writes many history records and watch for bulk insert exceptions in the logs. Check: all cases pass, and the bulk run completes with no exceptions.
Confirm the actuator endpoint responds
With the actuator starter enabled, call the Flowable endpoint at
/actuator/flowableon each node and confirm that it reports running process data without errors. Restrict access to the monitoring network and the accounts that need it, because the endpoint exposes runtime information about your processes. Confirm the endpoint name and exposure settings in the Spring Boot docs for your version. Check: each node returns a successful response from the endpoint, and the reported figures agree across nodes that share the same database.
Security and operational considerations on enterprise databases
Running Flowable on Oracle, SQL Server or DB2 puts the engine's tables, credentials and background job locks inside a database your enterprise already governs. The controls below follow that database into the Flowable deployment, so the engine's schema access, secret handling, traffic protection, recovery and lock monitoring are designed together rather than added after go-live.
Scope the schema account
Flowable needs a dedicated database account that owns or can alter only its own engine and history tables. Avoid running the engine as a DBA or schema owner account, because that account can change tables used by other applications. If your team cannot run DDL in production, agree with the DBA who creates and upgrades the tables before the engine connects, and confirm the exact privileges with the database vendor documentation for your version. Check that the account can read and write the engine tables it needs and nothing beyond them.
Keep database credentials out of config
The JDBC username and password for the engine should come from your secrets manager or the platform's secret store, not from a properties file committed to Git or baked into a container image. Inject the values at runtime and rotate them on a schedule your security team sets. Confirm that the engine's admin and default application accounts are also changed or disabled, since those are separate credentials that often survive a database credential rotation.
Encrypt database connections
Traffic between the Flowable engine and Oracle, SQL Server or DB2 carries process variables, task data and history, which can include personal or regulated information. Require encrypted JDBC connections and verify the server certificate chain against your internal certificate authority. Driver property names and TLS options differ by vendor and driver version, so confirm them with the JDBC driver documentation before you rely on them in production.
Back up and restore engine tables together
Process instances, tasks, jobs and history span many related tables, so a restore that brings back only some of them can leave running instances pointing at missing records. Take backups that capture the runtime and history tables at the same point in time, and include the engine's schema version. Test a full restore into a separate environment and start an engine against it, because a backup that has never been restored is not yet proven. Ask your DBA how the vendor's native backup tooling handles these tables.
Recover stalled async jobs
When several engine nodes share one database, each timer and asynchronous job is claimed by a node through a lock owner and a lock expiration time stored in the database. If a node crashes, its lock expires and another node picks the job up. Monitor lock owners and expiration times across nodes, and alert when locks stay held past their expiry or jobs stop moving. Confirm your database's clock handling and the lock settings you have configured, since misaligned node clocks or long-running transactions can delay recovery.
Limits to confirm in your environment before go-live
The research supplied for this topic does not give driver versions, bulk insert behavior or schema scripts for each database release, so these cards are questions rather than statements. Each one names something to confirm with the vendor, your DBA or your own test environment before a Flowable engine goes live on Oracle, SQL Server or DB2.
Which JDBC driver versions are certified
Ask which JDBC driver version Flowable expects for your exact database release, and whether your DBA can install it under the approved driver policy. Drivers differ in how they handle timestamps, large objects and transaction isolation, so a driver that connects may still behave differently under the async executor. Confirm the pairing in a test environment that mirrors production, including the database patch level.
How tenant handling treats empty strings
Ask how your engine version stores and compares an empty string tenant ID on Oracle, since Oracle treats an empty string as NULL. Check whether queries that filter by tenant return the rows you expect for default-tenant processes. Test deployments and queries with and without a tenant ID before you rely on tenant separation for data isolation.
Bulk insert behavior on DB2
Ask the Flowable team which bulk insert exceptions apply to DB2 for your engine version, and whether any history or runtime writes fall outside the normal batch path. Confirm how the engine reports a failed batch and whether it retries or rolls back the whole unit of work. Run a load test that reflects your expected process volume before you size the database.
Index behavior on SQL Server
Ask which nvarchar index changes your engine version includes for Microsoft SQL Server, and whether your existing schema or collation settings affect index size and key length limits. Confirm the index definitions the engine creates with your DBA, and check the query plans for the most frequent task and job queries. Record the results so future upgrades can be compared against them.
Schema scripts for each database
Ask which create, drop and upgrade scripts Flowable publishes for your database type and engine version, and whether they cover every table set your deployment uses. Confirm whether the engine can update the schema automatically in your environment or whether your change process requires DBA-run DDL. Keep the scripts under version control next to the application build so each upgrade has a tested path.
Licensing and table set acceptance
Ask your database vendor which licensing terms apply to your Oracle, SQL Server or DB2 edition, including core counts, processor licensing and any restrictions on embedded or third-party applications. Ask your DBA whether the Flowable table set, including history tables that grow over time, fits your storage, backup and retention standards. Get both answers in writing before the schema is created in production.
Questions teams ask before running Flowable on Oracle, SQL Server or DB2
What drives the cost of moving Flowable to Oracle, SQL Server or DB2?
Cost follows the number of database-specific changes in scope, more than the database product alone. The main components are discovery of your current Flowable version, the engines in use (process, CMMN, DMN and REST) and any custom Java delegates; driver and connection pool configuration for each environment; running the schema scripts in each target environment; testing the async executor and history behavior on the new database; and handover documentation. Most of this is one-time work. Recurring costs include driver patching and any support retainer you choose. Ask any quote to itemize these components, name the environments covered and state the Flowable version it targets. Most DeployOpen engagements are fixed-scope, so the written scope sets the price.
How long does a Flowable schema migration on these databases take?
The duration depends on drivers you control, not on a standard timeline. The main factors are the volume of active process instances and history rows if you carry data across instead of starting clean, how many environments need the change, whether your DBA reviews and runs the scripts or the team runs them, the change window your organization requires, the number of test cycles needed on each database, and whether the application code is ready for the target driver. Ask for a plan that lists each phase, the environments it covers and the approvals it depends on. Confirm timing against your own change calendar and the written scope before you commit a date.
What does Flowable need from our database administrators?
Your DBAs should own access, schema approval and production execution. Flowable creates and updates its tables through scripts or automatic schema handling, so the DBA needs to know which account runs DDL, which schema or tablespace holds the tables, how backups or restore points are taken before each change, and which privileges the engine account requires. Ask for the create, drop and upgrade scripts for each database, the engine and history table sets involved, and a rollback approach for each change. Where production DDL is restricted, the DBA runs the scripts and the engineering team verifies the results. Confirm the exact privileges and script names against the Flowable configuration documentation for your version.
Can our own developers run Flowable on Oracle, SQL Server or DB2 without outside help?
A team with prior Flowable experience and access to the target database can handle a single-engine move in a test environment first. The risk rises when the system has many process definitions, custom Java classes, active instances during cutover, or limited in-house expertise in the target database. Before deciding, list who owns driver configuration, performance testing, cutover and rollback. Check whether you can reproduce production load in a test environment, because the async executor and history behavior often show problems only under load. If several of these gaps exist, scope an outside review of the plan before the build starts. The decision should rest on named owners and tested rollback steps.
When should we bring in an outside partner for a Flowable database move?
Bring in outside help when the move carries production risk your team cannot test in-house. Typical triggers include no one on staff having run Flowable on the target database, active process instances that must continue through cutover, a need for independent verification within your change process, or a move combined with a Flowable major version upgrade. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so combining the two changes raises the effort. DeployOpen plans, implements, hardens, documents and supports Flowable in your own infrastructure, and it agrees scope and deliverables in writing before work starts.
Do Oracle empty string tenant rules affect our existing Flowable data?
They can, because Oracle handles empty strings differently from other databases, so tenant values stored or compared as empty text may behave differently after the move. Engineers should check every query, custom code path and REST filter that depends on an empty tenant identifier, and test process deployments, tasks and history that have no tenant set. Start by listing the tenant values in use today and finding any code that writes empty strings. Then run the same test cases on Oracle and compare results. Confirm the exact handling for your Flowable version in the release notes and the configuration documentation before you write the test cases.
Which JDBC drivers and database types does Flowable support?
The Flowable configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types. You still need to confirm the driver version, database version and connection settings that match the Flowable release you target, because support is defined per release. Two behaviors deserve specific tests before go-live: the nvarchar indexing improvements on SQL Server and the bulk insert exceptions on DB2. Check both against the release notes for your version, then reproduce the relevant workloads in staging. Keep the driver and connection settings in version control so each environment can be reviewed.
Can DeployOpen certify that our Flowable database setup is compliant?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access settings, backup procedures and change logs. Independent auditors and certification bodies issue audit reports, attestations and certifications. Ask any partner to list the evidence it will hand over at the end of the work, and ask your auditor which records they will test before the change begins. Flowable history and audit data can support some of these records, but confirm with your auditor which data they accept and how it must be retained for your control framework.
Can teams keep Camunda 7 data on these databases?
Yes, if the source data is in a supported state and the target database is on the supported list, but the answer should come from a planning run on your own data rather than from a general statement. Flowable's September 7, 2022 engineering post says Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history. In place means the migration works on the existing data store instead of exporting processes to a new platform and replaying them. For a team running Oracle, SQL Server or DB2, that matters because the database, its backup regime, its licensing and its DBA controls usually stay the same, and the migration becomes a schema and data change inside a system the organization already governs. The same post offers the free Flowable LEAP tool, which reports ahead of time what a migration involves. Run LEAP against a copy of your production Camunda 7 database before you choose a target, and treat its output as the input to the scope conversation, not as a formality.
Ask specific questions of the output. Which running instances would need special handling, how much history would be carried across, which custom Java delegates, listeners or scripts reference Camunda classes, and which database objects would be created or altered. Confirm with your DBA how the change would run on your engine, including whether the database user has the privileges the migration needs, how long a maintenance window would have to be, and how the team would roll back if a step fails. Check the Flowable documentation for the database types it lists for the target engine version before committing, because the supported list is part of the design decision. Where LEAP reports something you cannot resolve, plan that work and its cost into the fixed-scope agreement before the build starts, so the data question does not become an open-ended change request.
How DeployOpen scopes and delivers Flowable on your database
DeployOpen plans, builds, documents and hands over Flowable engines running on Oracle, Microsoft SQL Server or DB2 inside your own infrastructure. Engagements are fixed-scope, so the database work, driver choices and tests are agreed in writing before any build starts.
How we scope
- Confirm the exact database product and version your organization runs, and which Flowable release you plan to deploy.
- Record which engines, REST application or Spring Boot starters the database must serve, along with expected concurrency across nodes.
- Agree in writing how Oracle empty string tenant handling, SQL Server indexing and DB2 bulk insert behavior will be tested and accepted.
How we build
- Configure JDBC drivers, connection pools and schema settings for your chosen database, and check them against the Flowable configuration docs.
- Test process, case and decision deployments on a staging database that matches production, including async executor job pickup across nodes.
- Review database permissions and DBA-managed DDL steps with your database team before any change reaches production.
How we hand over
- Deliver the configuration, driver versions, schema scripts and test evidence as documentation your team can audit and reuse.
- Walk your DBAs and platform engineers through the runbook for upgrades, backups and recovery on your chosen database.
- Record open risks and the decisions behind them, so later changes to the database or Flowable version start from a known baseline.
How we support
- Fixed-scope delivery ends with an agreed handover, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover Flowable version upgrades and re-testing against database patch releases your organization applies.
- Ask for the support scope, response expectations and exclusions in the written quote before you commit to a retainer.
