In a deployment with full persistency (di + job server + runtimes) there's a need to handle the schema and DDL operations in an eager way, before we have even a single sonata running.

1. Runtime:
Currently a sonataflow service handles the migration, if set by the flyway configs

This approach brings complexity because a sonata flow starting , with another version, can potentially change the DDL in a way which is unsupporeted/distructive. It makes sense even to block this and allow this only for a controller-originated action.

2. Data Index and Job service
For those component, when using persistency, the schema initializtion is manually triggered.

There are various ways this can be addressed

• init containers
• sonataflowplatform controller, orchestrating a job and reporting the platform status accordingly

This means that the operator is responsible for the DDL of all components, and for the version that is used. Sonatas with custom image must use the base-image with the pinned version by the operator. otherwise no support.