SQL Schema Management for Production Deployments

[ricardas-buc]

Context:
I'm evaluating how EDC SQL schema could be handled in production environments. Ideally I want to use migration tools like Liquibase. There are some mentions that this is the expected way for production, but I cannot seem to find how it is expected to be done.

Questions:

1. Schema versioning: Are there any plans to publish migration changesets alongside releases, or will schemas continue to be modified in-place?
2. Breaking changes: How will schema-breaking changes (e.g., new NOT NULL columns) be communicated? Will release notes include migration guidance?
3. Artifact discovery: Is there a recommended way to programmatically identify all schema-containing JARs? I am considering an option where liquibase could use sql files from classpath, but this depends on how future schema changes will be published.
4. Production recommendation: What is the recommended approach for managing EDC schemas in production? Should integrators:

• Extract and version schemas independently
• Use sql-bootstrapper as-is with external backup strategies
• Another approach?

I noticed DR 2025-08-26 mentions Flyway placeholders as an example but leaves migration ownership to users. Looking for clarity on EDC's official stance.

Thanks in advance! :)

[paullatzelsperger]

Hey!

1. We do not now - nor do we have any plans to - provide any tooling for migrations, simply because it is (or can be) an extremely complex topic, on which most companies typically have their own opinions and for which they often have dedicated teams and tooling. Schema upgrades might come with data migration, and/or data conversion, which may require write access to the database to be temporarily suspended, and the DB to be put in a read-only mode, and that gets complicate rather quickly, and we haven't even touched on sharded or replicated DBs yet.
   The schemas we publish reflect the current state, we don't provide any diff, changesets or versioned migrations. After all, EDC is not a turnkey application, rather, it's an extensible platform.

2. We do annotate commits that contain breaking changes with the breaking change label, so just scan the release notes for that.

3. No, there is not.

4. No, we can't make any recommendations for the reasons stated above. Some projects use flyway to replicate and incorporate any changes from upstream EDC, but we neither officially support that, nor do we endorse it, nor do we recommend it. We are not against it either, we simply have no stance on this matter.

[arnoweiss]

In tractusx-edc, there's an extension that executes db schema migrations that you can take as input how your downstream project could tackle this.
https://github.com/eclipse-tractusx/tractusx-edc/tree/main/edc-extensions/migrations