Why DBA-managed Flowable schemas matter in production
Flowable can be set up so that a DBA, not the application, creates and changes the engine's tables. Turn off automatic schema updates in the engine configuration, then have the DBA review and run the create and upgrade scripts for your database and engine version. This matters when application accounts are not permitted to run DDL and the DBA owns every schema change, which is common in banks, healthcare organizations and other regulated teams. The engine keeps running state, job locks and timers in one table set and completed work in history tables, so the DBA needs to know which set each script touches. Confirm the setting names and where the scripts live for your version in the Flowable configuration docs.
For developers, the change is that the engine no longer creates tables when it starts in a shared or production environment. Local H2 setups can hide problems that appear on the production database, so the team should run the same scripts against a database of the same type and version during development and testing. Each engine upgrade becomes a schema change event, not a dependency bump. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4, so a move to that version changes the framework baseline as well as the tables. Several nodes sharing one database also depend on the lock owner and lock expiry columns used by the async executor, so every node must run the same schema version before any node starts processing jobs.
Schema management options and when each fits
This table compares three ways to decide who creates and changes Flowable tables: engine-managed updates at startup, a DBA running the provided DDL scripts, and a hybrid where the engine only validates the schema. Read each row against your change approval process, because the right choice depends more on who signs off on database changes than on the engine itself. Most regulated teams end up with the DBA-run option, and the table shows what that choice asks of your release process.
| Approach | What happens at startup | Who approves changes | Fit for regulated environments |
|---|---|---|---|
| Engine-managed automatic updates | The engine creates or alters Flowable tables when it starts, using the application's database credentials | The development team, implicitly, through the deployment that starts the engine | Usually a poor fit, because schema changes happen outside change control and the application account needs DDL rights |
| DBA runs the provided DDL scripts | Nothing is altered at startup; the engine expects the schema to exist and matching versions to be in place | A DBA or database change board, before the release that depends on the change | Usually the best fit, because scripts are reviewed, scheduled and kept as change records |
| Hybrid: engine validates without altering | The engine checks the schema matches its version and stops or warns if it does not, without changing tables | The DBA for changes, and the platform team for confirming the validation setting | Strong fit when the validation behavior is confirmed for your version and failures block the release |
| Application account privileges | Determines whether automatic changes can succeed at all | The security team, through the database role model | Confirm that the runtime account lacks DDL rights when scripts are DBA-managed |
| Script selection per database | Not applicable; the chosen script set must match the engine and database type | The DBA, with the engine version in the change ticket | Confirm the script folder for your database and version in the Flowable docs before review |
| Configuration key for schema behavior | Sets the startup behavior for the engine | Owners of the application configuration | Confirm the exact key name and allowed values for your Flowable version in the configuration docs |
| Rollback of schema changes | Not handled by the engine; the drop scripts are destructive and not a rollback path | The DBA with the application owner | Plan database backups and a tested restore instead of relying on drop scripts in production |
Setting up DBA-owned schemas for Flowable
This sequence moves Flowable table creation out of the application and into a DBA-controlled change, so the engine starts against a schema that someone reviewed and ran on purpose. Each step ends with a check that confirms the schema matches the engine version before production.
Confirm the database type and version
The DBA and the platform owner record the target database product and version in the change request. Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and MySQL versions below 5.6.4 lack millisecond precision, so older MySQL builds need a decision before work starts. Confirm the chosen product and version against the Flowable configuration docs. Done when the change request names the database, its version and the engines that will use it.
Obtain scripts for the engine version in use
The developer team identifies the exact Flowable engine version the application builds against, then takes the create, drop and upgrade scripts for that version from the project distribution for the target database. If you are upgrading, you need the scripts for the target version, and major releases can change the platform baseline, so check the release notes first. Confirm that the scripts come from the same release as the engine libraries in your build. Done when the script set, the engine version and the database are listed together in the change record.
Review and run the scripts in non-production
The DBA reviews the create and upgrade scripts for the database product, checks the table sets each enabled engine needs (process, CMMN, DMN, event registry and history), and runs them in a non-production schema. History tables grow with use, so the DBA also reviews storage, tablespace and retention settings for them. Confirm that the table sets appear as expected in the catalog and that the drop script is kept for rollback in a non-production environment. Done when the DBA signs off on the non-production schema and its table list.
Disable automatic schema updates in configuration
The developers set the engine's schema update property to a value that prevents the application from creating or altering tables at startup. The exact property name depends on your engine version and how you embed Flowable, so confirm it in the configuration docs for that version before you change anything. Remove or restrict DDL privileges for the application database user so the setting cannot be bypassed by accident. Done when the configuration is committed to version control and the application user can read and write data but cannot run DDL.
Point the application at the pre-built schema
The developers update the JDBC URL, schema name, credentials and connection pool settings so the application connects to the schema the DBA prepared. Size the connection pool with the async executor in mind, because timers and asynchronous jobs take connections as well as user requests. Store database credentials in your secrets mechanism rather than in plain configuration files. Done when the application configuration in each environment names the prepared schema and the test deployment starts without errors that mention connection or schema problems.
Verify the engine starts and reads the tables
Start the engine and confirm the startup log reports no schema mismatch or missing table errors. Then deploy a small test BPMN, CMMN or DMN model, start an instance, and read it back through the Java API or the REST application. For Spring Boot applications, the actuator endpoint at /actuator/flowable reports on running processes and helps confirm the engine is reading live data. Run a timer or asynchronous job to confirm the job tables and lock columns work. Done when the test deployment, instance and job all complete, and the DBA confirms the schema matches the signed-off script set.
Security and access controls for schema changes
Schema creation and upgrades are the highest-privilege operations in a Flowable database, so the controls around them matter as much as the scripts. The cards below cover who runs DDL, where the drop script may run, how scripts move through review, and how credentials and changes are recorded. Check each one against your own database platform and the Flowable configuration docs before the first production run.
Separate DDL from the runtime account
Run the create and upgrade scripts under a database identity that DBAs control, and give the Flowable application a separate account for normal reads and writes. Keeping these identities apart means a compromised application cannot change table structure. Ask your DBA to confirm the exact privileges the runtime account needs, since the Flowable configuration docs describe the schema mechanism but do not prescribe a privilege set for every database.
Restrict the drop script
The drop script removes Flowable tables and their data, so it should be unavailable in production and limited to controlled non-production environments. Confirm that no pipeline job, deployment tool or application startup path can invoke it against a production schema. Treat any request to run it as a change that needs the same approval as a data deletion.
Version control scripts with approval
Store every create, drop and upgrade script in Git alongside the Flowable version it targets, so each database change has an author, a reviewer and a history. Require a DBA sign-off on each merge that touches schema files. Tie the approved script version to the change ticket so auditors can match what ran to what was reviewed.
Protect database credentials
Keep the DDL account and the runtime account in a secrets store with separate access policies, and rotate them on a schedule your security team sets. Do not place DDL credentials in application images, CI variables visible to all developers, or shared configuration files. Confirm which credential the migration job uses and that it is revoked or disabled after the change window.
Audit every schema change
Log who ran each script, against which database and at what time, and keep those logs outside the database they describe. Compare the database's own DDL audit facilities with your change tickets at regular intervals. An unexplained table alteration should trigger the same investigation as any other unauthorized database change.
Block runtime schema alteration
Disable automatic schema updates in the Flowable engine configuration for production so the application never alters tables at startup. Then verify this with a test: start the engine under the runtime account and confirm that it cannot issue DDL. A startup that fails on a schema mismatch is the expected and safer result, because it shows the scripted upgrade was skipped.
Upgrading tables across Flowable versions
When you move between Flowable major versions, the schema change is only one part of the work, and it has to be planned together with the application upgrade. Flowable 8.0.0 was released on February 27, 2026, following 7.2.0 on August 21, 2025 and 7.1.0 on October 7, 2024. The 8.0.0 release moves the framework to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3, so an application still on Spring Boot 3 cannot simply take the new engine jar with a new schema script. The 7.0.0 line made a similar baseline change, moving to Java 17, Spring Boot 3 and Jakarta EE. Your DBA should receive the upgrade script and the application change request as one package, with the same target version and the same change window, so the schema and the running code never disagree about which tables and columns exist.
Before you schedule the change, confirm in the Flowable 8.0.0 release notes which upgrade scripts the release requires for each database you run, and whether any version step must be applied in sequence rather than skipped. The same check applies to any jump that crosses 7.0.0, so read the Flowable 7.0.0 release notes for the baseline changes that affect your runtime. Ask the Flowable team or your partner to confirm the script set for your exact source and target versions, and record the answer in the change ticket. Also confirm which history tables the upgrade touches, because history volume is often the largest part of the migration window and the part DBAs most often need to size in advance.
Plan a rehearsal on a copy of production data that runs the full order: take a backup, apply the scripts, deploy the matching application build, start the engine, and confirm that the async executor picks up jobs. Keep the rollback path explicit. Once a schema script has run, returning to the old engine may not be possible without restoring from backup, so the backup must be verified and the window for restore agreed before the change starts. Schedule the application deployment so that no old pods or nodes continue writing against an upgraded schema, and no new code starts against a schema that has not been upgraded.
Limits to confirm before you choose this approach
DBA-managed scripts are only as good as their match to your exact Flowable version, database and table sets. The cards below are the questions to settle with the vendor docs and a test environment before your DBAs take ownership of schema changes.
Script set matches your version
Confirm that the create, drop and upgrade scripts you run come from the same Flowable release and engine set you deploy. A script written for one engine version can omit tables or indexes that another version expects. Check which engines your application actually uses, since the scripts are organized by engine, and compare the script list against the tables the running engine creates in a test database.
History table growth
Ask how history tables are handled once they grow large, including whether your history level and retention settings are fixed in the schema or set in configuration. Plan who purges or archives history, how that work is scheduled, and whether the DBA team or the application owns it. Test purge runs on a copy of production volumes before you rely on them.
Database version support
Confirm that your exact database product and version are supported by the Flowable release you chose, not just the database family. The configuration docs list supported database types, and they note that some older MySQL versions lack millisecond precision. Check the minimum version for each database and any driver requirements before the scripts are generated.
Tenant handling differences
Confirm how tenant identifiers are stored and queried on each database you use. Some databases treat empty strings differently from NULL, which can change how tenant-scoped rows are matched and indexed. Test tenant-scoped queries and uniqueness constraints on the target database rather than assuming the behavior matches your development database.
Database-specific tuning
Ask whether the generic scripts need changes for tablespaces, index types, character sets, collations or storage parameters at your site. Your DBAs may need to adjust these before running them, and any change must be reflected in the scripts that later upgrades rely on. Record every deviation so the next upgrade does not silently undo it.
Rollback of schema changes
Confirm what rollback means for each schema change. The drop script removes Flowable tables, so it is not a rollback for an upgrade. Ask whether the upgrade scripts are reversible, and plan database backups or point-in-time recovery before each run. Rehearse the full sequence, including restoring data and restarting engines on the previous version, in a test environment.
Questions teams ask before running Flowable schemas through a DBA
How much work is it to hand Flowable schema creation to a DBA?
The work is less about the scripts themselves and more about agreeing on how they get reviewed, applied and verified in each environment. Teams usually need to pick the database type, decide which engine and history table sets are in use, generate the create, drop and upgrade scripts for that combination, and have the DBA review them against local standards. Effort rises with the number of environments, the number of Flowable engines and the database platform. Ask any partner to show the script inventory and review steps in writing before agreeing a scope.
Can our internal team run this without outside help?
Often yes, if someone on the team already knows Flowable's table layout, has access to a non-production database that matches production, and can run the generated scripts under change control. The harder parts are usually the first upgrade, where table sets and version-specific changes must line up, and turning off automatic schema updates without breaking startup checks. An outside partner adds the most value when the team lacks prior Flowable schema experience or when the first rollout has to pass a formal change review. Decide this after a short internal trial against a copy of your database.
What do we need from our DBA and security teams?
The DBA team typically reviews the create, drop and upgrade scripts, confirms tablespace, index and privilege requirements, and agrees on how scripts are executed and logged. The security team usually checks which database account runs the DDL, who holds that credential, and whether the application account is limited to data operations. Both teams should also agree on rollback steps and on where script output is stored as change evidence. Ask for these decisions to be written into the runbook before the first environment is touched.
How long does a first schema rollout take in our environment?
No general duration is published for this work, so the answer depends on your own environment. The main factors are your change approval cycle, how many non-production environments must be updated first, the database platform and how many Flowable engines share it. Ask for a timeline built from your change calendar and environment list, with the review and test gates shown as separate steps. Treat any single number offered without that context as unverified.
What drives the cost of DBA-managed Flowable schemas up or down?
Cost follows the scope of schema review, environment work, testing and runbooks. Review cost rises with the number of engines, history table sets and database types. Environment work rises with the number of stages that need the scripts applied and verified. Testing cost depends on how many upgrade paths you must prove, and runbook cost depends on how many teams must follow the procedure. Each of these is paid either to your staff or to a partner, so ask any quote to list each component separately, along with what is one-time and what recurs with each Flowable upgrade.
Does the DBA-managed approach change how we upgrade Flowable later?
Yes. With automatic schema updates turned off, every Flowable version change needs a matching upgrade script applied by the DBA before the new application version starts. Major releases can also change the platform baseline, so the upgrade script is only part of the work. The Flowable 8.0.0 release notes, released on February 27, 2026, describe a move to Spring Framework 7 and Spring Boot 4, which affects the application side of any upgrade. Plan schema upgrades and application upgrades as one change, and confirm the exact script set for your target version with Flowable's documentation.
What should we check before turning off automatic schema updates?
Confirm that the database already contains the full Flowable table set for the version you run, that the application is configured to validate rather than create tables, and that a failed startup is caught and reported. Check the Flowable configuration documentation for the schema update setting used by your engine, and test a cold start against a copy of production. Also verify that the database type you use is in the supported list, including the note that MySQL versions below 5.6.4 lack millisecond precision. These checks are the core of the first-rollout test plan.
What DeployOpen delivers for schema management
On a fixed-scope engagement, DeployOpen plans how Flowable's table sets will be created, upgraded and retired in your environment before any script is written. The plan fixes which engines are in use (BPMN, CMMN, DMN, event registry and the history tables you choose to keep), which database type you run, and who applies each script in each environment. It also records the automatic schema update setting you intend to turn off, so the DBA's role and the application's startup behavior are agreed in writing rather than discovered in production.
Next, DeployOpen prepares the scripts and a runbook for your target database. That covers the create and drop scripts for the engine table sets, the upgrade scripts that move an existing schema from one Flowable version to the next, and the verification queries your DBA runs after each step. Where your database is H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server, the scripts are written for that dialect and checked against the settings in the Flowable configuration docs. Upgrade scripts are tied to the exact source and target versions, so the runbook names both.
DeployOpen then tests the create and upgrade paths in a copy of your environment, using your database version, your schema owner and your permissions model. Each test records the application startup result, the table counts and any failed jobs. The output is a set of evidence your team keeps: the approved plan, the script hashes, test logs and the change record for each run. DeployOpen prepares these artifacts for your controls. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those determinations, and you should confirm with them which evidence they expect.
How DeployOpen scopes and supports Flowable schema work
DeployOpen treats DBA-managed Flowable schemas as a delivery item with written scope, reviewed scripts and a documented handover. Our work covers the create, drop and upgrade scripts for your database, the engine and history table sets you choose, and the configuration that turns off automatic schema updates in your environment.
How we scope
- The written scope names each target database type and the Flowable engines whose tables your DBA will create.
- We list which history table sets are in scope and which are excluded, with the reason for each.
- The scope states who runs the scripts, in which environments, and who approves each upgrade stage.
How we build
- We generate create, drop and upgrade scripts from the engine version you select, and review them against your database standards.
- We test each script on a copy of your database engine and version before the DBA receives it.
- We set the engine configuration so automatic schema updates are off in production and the application fails fast on mismatch.
How we hand over
- You receive the script set, a run order, rollback notes and a checklist the DBA can follow without the build team.
- The handover documents which Flowable version each script set matches and how to confirm the schema version at startup.
- We walk your DBA and platform team through a dry run in a non-production environment before the first production change.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- When you move to a newer Flowable version, we issue a revised script set and an updated upgrade checklist for review.
- Support requests are answered against the scope and the versions you agreed, so changes are tracked in writing.
