Why teams run Flowable on PostgreSQL
PostgreSQL is one of the supported Flowable database types, so a team moving off H2 or a demo setup to a shared production database can keep the same engine and change the persistence layer. The work is configuring the JDBC connection, creating the schema, sizing the connection pool for the async executor, planning backups, and watching the history tables, which grow fastest. The Flowable configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types, so PostgreSQL is a standard choice rather than a custom integration. Confirm the driver and engine versions you intend to run against the Flowable configuration docs before you write the first connection string.
Flowable is licensed under Apache 2.0 and can be embedded as a JAR in a Java SE application, a servlet container, a Spring application or a Java EE server, or it can be used over HTTP through the Flowable REST application. Whichever model you choose, every node that runs process or case work reads and writes the same database, so the database becomes shared infrastructure with its own owner, availability target and change process. PostgreSQL itself is released under the PostgreSQL License, a permissive license similar to the BSD and MIT licenses, which matters if your legal team reviews the full stack before deployment. Ask your platform team to name who owns the database instance, its backups and its upgrades before the Flowable rollout is scheduled.
The decisions that matter most come after the first successful start. Pool size, lock behavior for timers and asynchronous jobs, and history retention all shape how the database behaves under real process volume, and none of them is visible in a single-user test. Plan for a backup and restore test, confirm which PostgreSQL major version your organization supports under its own policy, and decide who reviews history growth each month. Treat the PostgreSQL setup as a production system from day one, because a shared database that is misconfigured for Flowable will affect every application that depends on it.
Which PostgreSQL configuration options fit which situation
This table compares the PostgreSQL topologies a Flowable deployment commonly considers, from a single primary to replicas and a connection pooler. Read each row for when the option fits and what it changes for the engine, since Flowable writes only to the primary and failover is not handled by PostgreSQL alone.
| Option | When it fits | What it changes for Flowable | What to confirm |
|---|---|---|---|
| Single primary | Non-critical or early environments where a short outage for restore is acceptable | All engine reads and writes go to one server; recovery depends on backups and restore time | Recovery time and data loss you can accept, and who performs the restore |
| Primary with hot standbys (asynchronous) | Production systems that need a readable copy and can accept some data loss on primary failure | Standbys serve read-only queries but take no engine writes, so the Flowable JDBC URL still points at the primary | Replication lag under your peak load and how reporting queries are routed |
| Primary with synchronous standby | Systems where a committed process transaction must exist on a standby before the commit returns | Each commit waits for the standby, which can slow write-heavy runtime and history tables | Latency between sites and whether the standby set can tolerate a slow or missing node |
| Automatic failover with external tooling | Production clusters that must promote a standby without an operator | PostgreSQL does not detect primary failure or notify standbys, so a separate tool must do this and update the connection target | Which tool, how it fences the old primary, and how the Flowable pool reconnects |
| Connection pooler such as PgBouncer | Many nodes or pods each opening JDBC connections to one database | Limits server-side connections, but transaction pooling interacts with session state and prepared statements, so test the Flowable driver settings first | Pool mode, prepared statement handling and the pool size per engine node |
| Pooler in front of a replicated cluster | Multi-node Flowable with both pooling and failover needs | Pooler must point to the current primary after promotion, and must not send engine writes to a standby | How the pooler target is updated and tested during a failover drill |
| Read-only reporting standby | Dashboards or analytics that query history without loading the engine | Good for reporting queries; any job that writes through the engine must use the primary | Which history queries run on the standby and how stale results are handled |
Setting up Flowable on PostgreSQL step by step
This sequence takes a team from choosing a supported PostgreSQL version to a Flowable engine that starts, reports healthy, and runs against a database that has passed a restore test. Each step ends with a check so the next step starts from a known state.
Choose a supported PostgreSQL major version
Confirm which PostgreSQL major version your platform team will run before anything else is configured. Check the versioning policy for the end-of-support date of each candidate, and choose a version whose support window covers the expected life of the Flowable release you plan to run. Your team or a partner can make this decision, but the platform owner should sign it off. You know this step is done when the chosen version and its end-of-support date are written into the design record and the target database server is provisioned at that version. Confirm the supported version list with PostgreSQL before you commit, because support dates are published by the project and may change.
Create the database and a dedicated role
Create a dedicated database and a login role for Flowable, granting that role ownership or the privileges it needs on its own database only. Do not reuse an administrative account or the default postgres superuser. Store the password in your secrets manager rather than in the configuration file. Set the authentication method for the Flowable host in pg_hba.conf to SCRAM, since PostgreSQL has deprecated MD5 password authentication. You know this step is done when a test connection from the Flowable host succeeds with the new role and fails with a deliberately wrong password.
Set the JDBC URL and driver in Flowable configuration
Set the JDBC URL, username, password and the PostgreSQL driver in the Flowable configuration for your deployment, whether that is the Spring Boot properties, the REST application properties or the engine configuration. Add the PostgreSQL JDBC driver to the classpath or image, and check the Flowable configuration documentation for the database type value that matches PostgreSQL. Keep the connection settings in externalized configuration so the same artifact runs in each environment. You know this step is done when the engine log shows the PostgreSQL database type and the driver version it loaded, with no fallback to H2.
Decide between automatic schema creation and DBA-managed DDL
Decide whether Flowable creates and upgrades its tables at startup or whether a database administrator applies scripts that the platform team reviews. Automatic creation is quicker for a non-production environment and for a first build. Production often requires DBA-managed DDL because schema changes go through change control. Record the decision and the owner of schema changes, and turn off automatic schema updates in production if your DBAs own the schema. You know this step is done when the chosen mode is set in configuration for each environment and a test startup in the target mode produces the expected table set in the Flowable schema.
Size the connection pool against async executor threads
Size the JDBC connection pool with the async executor's thread count and the number of Flowable nodes in mind. Each async executor thread can hold a connection while it works on a job, and the lock acquisition used to coordinate nodes also uses the database. Keep the total connections across all nodes below the PostgreSQL max_connections value minus headroom for administrators and other applications. If you run a pooler such as PgBouncer, confirm its pool mode is compatible with the transactions Flowable uses. You know this step is done when a load test shows the pool does not queue or time out while jobs run, and the total connection count across nodes is documented.
Verify startup and actuator health
Start one Flowable node and confirm the engine initializes against PostgreSQL without errors in the log. If you run Spring Boot starters, call the health endpoint and the Flowable actuator endpoint at /actuator/flowable to confirm the engine reports running process information. Confirm that the async executor is active and that a test timer or job is picked up and completed. Check that the actuator endpoint is restricted to your monitoring network rather than exposed publicly. You know this step is done when the health endpoint reports up, the Flowable endpoint responds, and a test process instance completes end to end.
Confirm backup and restore with a test restore
Take a backup of the Flowable database using your chosen method, such as continuous archiving with point-in-time recovery or logical dumps for smaller environments, and restore it into a separate PostgreSQL instance. Start a Flowable node against the restored database and confirm that in-flight process instances, jobs and history are present and that the async executor can continue them. Record how long the restore took and what data was missing from the last backup point. You know this step is done when the restored engine runs a test instance to completion and the restore procedure is written down with its owner. Ask your backup vendor or team to confirm that the procedure meets your recovery objectives before go-live.
Securing the PostgreSQL connection and data
The Flowable engine holds process variables, task data and full history in the same database, so the connection and its backups carry the same sensitivity as the applications themselves. The cards below cover how clients authenticate, how traffic is protected, how database roles are split, and how copies of the data are handled. Each one names a decision your team should make before the schema is created.
Choose the authentication method
PostgreSQL documents several client authentication methods, including password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth. For password logins, use SCRAM rather than MD5, since MD5 password authentication is deprecated in PostgreSQL 18. Confirm with your DBA which method your directory and security standards support, and check that the Flowable JDBC driver and your pooler can negotiate it.
Encrypt JDBC traffic with TLS
Process variables and history often contain customer, employee or account identifiers, so the JDBC connection should be encrypted end to end. Set the SSL mode in the JDBC URL to verify the server certificate, not just accept encryption, and point the client at your internal certificate authority. Ask whether the connection pooler and any load balancer terminate TLS, because that decides where traffic is exposed in clear text.
Separate the schema owner from the runtime user
Use one role to create and alter the Flowable tables and a different, more limited role for the application at runtime. The runtime account needs data access for reads and writes but no rights to drop tables or change the schema. This split also supports the DBA-managed schema approach, where DDL is run by a controlled change process rather than by the application on startup.
Restrict network and host access
Limit which hosts can open connections to PostgreSQL by configuring host-based rules in the server's access file, and bind the listener only to the interfaces you need. Allow the Flowable pods, servers or pooler and the administration network, and deny everything else. Review these rules whenever you add a new Flowable node, because each node is a new client of the same database.
Encrypt and restrict backups
Base backups, dumps and archived WAL files contain everything the engine stored, including completed process variables and audit-relevant history. Encrypt them at rest, limit who can restore them, and set retention that matches your data policy rather than keeping every copy indefinitely. Test restores in an isolated environment, because a restored copy of production data is itself a sensitive dataset.
Document the controls you rely on
Record which authentication method, TLS settings, role grants and backup protections apply to each environment, and who approved them. Keep this record with your Flowable deployment documentation so auditors and security reviewers can trace a control to a setting. Confirm the specific control expectations with your assessor and the relevant standard before you describe them as compliant.
Which history tables grow fastest and how to plan for them
History growth is the cost of running Flowable on PostgreSQL that most teams underestimate, and it is decided by three things: how long completed instances stay in the database, whether anything removes them, and how much the history level records for each instance. Flowable writes history rows as process and case instances run, and those rows stay after the runtime rows are gone. Before you size storage or set a backup window, confirm in the Flowable configuration documentation which history level settings exist for each engine you run, what each level records, and which retention or cleanup options the engine provides. Those options, not the database, determine whether history grows without limit.
Measure rather than estimate. In a non-production environment that runs a representative mix of your processes, use PostgreSQL's own catalog and size functions to record the size of each Flowable history table, along with its row count, after a known number of completed instances. Repeat the measurement after a bulk test, then extrapolate using your actual monthly volume. Pay attention to the tables that receive one row per activity or variable change, because they usually dominate. Also check index sizes, since indexes on history tables can grow as large as the data they cover and affect both backup size and restore time. Keep the measurements with the test date and the history level you used so the numbers can be repeated after a change.
Decide retention with the people who own the records. Compliance, audit and business teams often need history for a defined period, and that period may differ from the period the engine needs to keep data for operational work. Write the retention rule, the deletion method and the owner before go-live, and test the cleanup job on a restored copy of the database so you know how long it runs and how much it locks. Plan backups around the result: a retention policy that reduces history also shrinks the base backup, and PostgreSQL's continuous archiving documentation describes the point-in-time recovery mechanism whose storage needs grow with write volume, including history writes. Ask your DeployOpen contact to include these measurements and the retention test in the written scope.
Limits to confirm in your environment
Several limits in this stack sit outside the Flowable engine itself: how PostgreSQL fails over, how it moves between major versions, and which Java and Spring baseline the Flowable release line expects. Each card names one limit and the check to make before you commit to a design.
Failover needs external tooling
PostgreSQL provides hot standbys and synchronous or asynchronous replication, but it does not detect a failed primary or notify standbys on its own. Automatic promotion therefore depends on a separate tool that you select, operate and test. Confirm who owns that tool, how it fences the old primary, and how the Flowable async executor reconnects after a switch. Test the whole path, not only the replication setup.
Minor updates versus major upgrades
Minor PostgreSQL releases do not change the internal storage format, so they replace executables and require a restart. Major upgrades are a different operation, using dump and restore, pg_upgrade or logical replication. Plan Flowable maintenance windows around the major path, and rehearse it against a copy of the schema that includes the history tables. Ask who runs each path and how rollback works.
Flowable release line sets the baseline
The Flowable release line determines which Java, Spring Framework and Spring Boot versions are supported. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped Spring Boot 3, while Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE. Your PostgreSQL target does not change this choice, so fix the Flowable line first and then confirm the database versions it supports.
Driver and database version pairing
The JDBC driver version must match both the PostgreSQL server version and the Flowable release you run. Confirm the pairing in Flowable's configuration documentation before you upgrade either side, because a driver that connects can still fail on a feature the engine uses. Record the chosen driver version in your build and in your upgrade checklist so the pairing is reviewed every time either component moves.
Support windows for PostgreSQL versions
Each PostgreSQL major version receives support for five years after its initial release, and older versions fall out of support on fixed dates. Check the current support table when you choose a version, because a Flowable deployment that outlives its PostgreSQL major version will need a planned upgrade. Ask your database operations team which version they will commit to and when that version leaves support.
Questions teams ask before running Flowable on PostgreSQL
How much effort does a PostgreSQL setup for Flowable take?
The effort depends mostly on how many Flowable engines share the database, how many nodes run the async executor, and whether PostgreSQL already exists in your environment with the high availability, backup and pooling you need. A single engine on a managed PostgreSQL instance with an existing backup policy is a small task. A setup with several engines, a connection pool sized for the async executor, replication, tested point-in-time recovery and a planned major upgrade path is a much larger one. Ask any partner to split the quote into database provisioning, Flowable configuration, schema creation, pooling, backup testing and operational handover, so you can see which parts your own team already covers.
Can our team set up Flowable on PostgreSQL without a partner?
Yes, a team with Java and database experience can do it, provided it has someone who owns the PostgreSQL cluster and someone who owns the Flowable configuration. The Flowable configuration docs list PostgreSQL among the supported database types, so the JDBC settings and engine properties are documented. The harder parts are judgment calls: how many connections each node may open, how the async executor's lock expiration interacts with your pool, and how you will prove a restore works. Teams without that experience in-house often bring in a partner for those decisions, then run the system themselves afterward.
What does the work need from our DBA and platform teams?
Your DBA team owns the database side: cluster topology, roles and privileges for the Flowable schema, backup storage, retention and restore testing, and the choice of authentication method. Your platform team owns the runtime side: how Flowable nodes reach the database, secrets distribution, network paths through any pooler, health checks and restarts. Schema changes need an agreed path too. If developers cannot run DDL in production, the DBA team will need the create and upgrade scripts for the engine and history table sets before go-live. Agree these owners in writing at the start, because most delays come from questions nobody was assigned.
How are PostgreSQL backups and point-in-time recovery tested?
A backup counts only after a restore into a separate environment has been run and checked against Flowable. The PostgreSQL continuous archiving documentation describes base backups combined with archived WAL segments, which allow recovery to a chosen point in time. A useful test restores to a point before a known process deployment, starts a Flowable node against the restored schema, and confirms that running process instances, timers and jobs appear as expected. Record how long the restore took and whether the async executor resumed cleanly. Ask your provider to show the test plan and the evidence it produces, not only the backup configuration.
How are major PostgreSQL upgrades planned with Flowable running?
Plan the major upgrade as a change to the database and to the Flowable configuration together. The PostgreSQL upgrading documentation covers three approaches: dump and restore with pg_dumpall, pg_upgrade, and logical replication. Logical replication works between different major versions and can keep downtime to several seconds, which matters when Flowable jobs run continuously. Confirm that the Flowable version you run supports the target PostgreSQL major version before you schedule the change. Minor releases do not change the storage format, so they are simpler: replace the executables and restart. Keep a tested rollback path for each approach.
What cost components does a quote for this work cover?
A quote usually covers four components: discovery and design of the database topology and pool sizing, implementation of the PostgreSQL and Flowable configuration, testing of backup restore and failover behavior, and handover with documentation. Some items recur, including PostgreSQL infrastructure, licensing of any managed service you choose, patching windows and support retainers. PostgreSQL itself is released under the PostgreSQL License, so the software carries no license fee. Ask the provider to separate one-time work from recurring support, to name the environments it will build, and to state which tests are included in the fixed scope.
Which PostgreSQL versions are still supported for a new Flowable setup?
Choose a version that is still within the PostgreSQL support window for the whole life of the system, not just at launch. According to the PostgreSQL versioning policy, versions 14 through 18 are currently supported, with end dates that run from November 12, 2026 for version 14 to November 14, 2030 for version 18. Version 13 and earlier are unsupported. Check the Flowable release you plan to deploy against the PostgreSQL version you pick, and schedule the next major upgrade before the end-of-support date of the version you start on.
How DeployOpen scopes and delivers a PostgreSQL setup for Flowable
DeployOpen plans, implements, hardens, backs up and documents Flowable inside your own infrastructure, and the scope for a PostgreSQL setup is agreed in writing before any work starts. For this topic, that scope usually covers the PostgreSQL cluster that holds the Flowable schema, the JDBC settings in each engine or REST application, the connection pool sizing that the async executor depends on, the backup and restore procedure, and the history table retention rules. Most engagements are fixed-scope, so the written scope lists the deliverables, the environments involved and the acceptance checks, such as confirming that several Flowable nodes can share one database without duplicate job execution. Ask for the scope to name which Flowable engines and deployment form you run (embedded in Spring Boot, the Flowable REST application or both), because that choice changes which settings and tables are in scope.
Before scoping, the team should confirm a few facts about its own environment: the PostgreSQL major version it plans to standardize on, who owns the database platform, whether high availability is expected to be automatic (PostgreSQL itself does not detect a primary failure, so an external tool is needed), and how backups must meet the retention commitments the organization already has. DeployOpen can document these decisions as part of the deliverables so that operations staff can run the setup after handover. Retainers are available for ongoing support, including reviewing history growth, applying minor PostgreSQL updates and planning the next major upgrade, if your team wants continued help after the initial delivery.
Quotes follow from the written scope, and DeployOpen does not publish a price list. When you request a quote, ask for each deliverable to be listed separately, with the environments it covers, the systems you must provide access to, and the work that recurs after handover (such as backup restore tests and upgrade reviews) as distinct from one-time setup. Ask how the scope handles changes found during the work, and what happens if a dependency such as a load balancer or identity provider needs its own work. DeployOpen prepares systems and evidence that your own auditors can review, but it does not issue audit reports, attestations or certifications.
