When we use the   kogito-addons-quarkus-jobs-service-embedded, (eventually combined with the kogito-addons-quarkus-data-index-inmemory or the kogito runtimes jdbc persistence) we have the following situation:

As part of the start-up procedure, the jobs service tables are created

1) in the "default" database (i.e. the default datasource)

2) and in the "jobs_service" database (i.e. the database created for the jobs_service datasource introduced by the jobs service embedded addon)

Then, when the application is running, etc, the jobs related information is written in the tables in the jobs_service DB, which is the desired behavior.

But, flyway, are updating both databases, which might introduce an issue in case the runtime persistence is enabled and we have a collision of tables, or version numbers in the xxxxx.sql files used by flyway.

The correct functioning is that only the jobs_service database should be updated.