Hi Joe,
Thanks for reaching out,
In order to fall back if an upgrade faces issues, you must redeploy the previous images, but also restore the repository from the back up that was made before the upgrade process (if the upgrade has reached the repository modification phase).
As the upgrade of the data locations is a separate upgrade, the data locations will still be ok.
Any upgrade made on the repository (or data location) is definitive and cannot be reverted (a restore from a back up is needed).
About the newest, not officially supported PostgreSQL versions for earlier xDM versions, we cannot encourage nor validate the use of unsupported versions of PostgreSQL, especially in a production environment, even knowing that PostgreSQL has not introduced any breaking changes.
We are pleased to announce that the Semarchy Data Platform is the new xDM, with its DM module, more information here. Therefore, there is no version 2026.1 planned for xDM.
Thanks,
Guillaume
Joe Patton
Hello All,
We are still running version 2024.1 LTS in Azure Kubernetes/Azure Postgres Flexible Server v14.19. We need to move to new versions of both Semarchy xDM and Postgres before the end of 2026.
- we are looking at moving to 2026.1 LTS which should be general availability soon?
- we are looking at either Azure Postgres Flexible server V16 or V17
Questions:
1. If we run into issues after deploying a new xDM version, are there any other steps required for falling back other than deploying the previous version's Active/Passive docker images? Would there be any fallback steps to execute against the database Semarchy repository or data location schemas?
2. We were considering performing the Postgres instance upgrades a few months ahead of the application upgrades. If we are currently on xDM 2024.1.1 LTS, I believe the latest certified version of Postgres is v15. Would we potentially have support issues if we upgraded to Azure Postgres Flexible Server versions 16 or 17 while still running xDM 2024.1.1?
Regards,
Joe Patton