DBeaver Workspace Migration Driver Compatibility During Rollback

Question

Workspace version isolation and driver directory separation
DBeaver creates a new version-specific workspace directory (for example ~/.dbeaver5) during a major upgrade and attempts to migrate connections, scripts, and preferences from the previous workspace. The bundled JDBC drivers, however, reside inside the DBeaver installation folder rather than the workspace. When a rollback is performed by deleting the new workspace and restoring the old one, the installation directory still contains the newer driver versions that shipped with the upgraded release.
Unresolved constraint
There is no documented mechanism that automatically downgrades or isolates drivers to match the restored workspace. The migration wizard also does not validate whether saved passwords or SSH tunnel configurations remain compatible with the encryption libraries in the older version.
Specific questions

Which driver files must be manually reverted alongside the workspace to guarantee connection compatibility after a rollback?
Does the migration wizard expose any flag or log that records which driver versions were active before the upgrade?
Can a portable installation layout be used to atomically restore both workspace and driver set without affecting system-wide file associations?

Tasadduq Burney · Answer

Answer
To keep connections working after rolling back a DBeaver upgrade, you must manually replace the JDBC driver JARs that were updated during the upgrade with the versions that were present before the upgrade.
Likely explanation
The migration wizard moves workspace data but leaves the installation‑bundled drivers untouched, so the newer driver files remain on disk and can cause class‑version mismatches when the older workspace tries to load them.
Confirmed facts

Driver JARs reside in the installation’s drivers (or plugins) directory, not in the workspace.
The migration wizard does not write a dedicated flag or log entry that lists the exact driver versions active before the upgrade; the only trace is the generic dbeaver.log in the workspace, which records driver loads but not version numbers.
When DBeaver is launched in portable mode, both the workspace and the driver set are stored inside the same portable folder, allowing an atomic restore of workspace + drivers without touching any system‑wide installation.

Steps needed for this case

Identify the driver JARs that changed between the pre‑upgrade and post‑upgrade installation (e.g., by comparing timestamps or using a backup of the drivers folder).
Replace each newer JAR with the older version from the backup or vendor archive.
Start DBeaver with the restored workspace and verify that connections load without driver‑related errors.
If you need to know exactly which versions were in use before the upgrade, provide the list of driver versions or a backup of the drivers folder; without that detail you must rely on timestamp/version comparison.

DBeaver Workspace Migration Driver Compatibility During Rollback

Workspace version isolation and driver directory separation

Unresolved constraint

Specific questions

1 answer

Answer

Likely explanation

Confirmed facts

Steps needed for this case

Your perspective belongs here.

0 question comments