Updates Recovery and Restores

Updates, Recovery and Restores

LakeDB provides a recovery-first upgrade path. The application can notify you about releases, download verified packages, preserve every connection workspace, protect local migrations and create a recovery artifact before a restore changes data.

Check for updates

Automatic checks are enabled under Preferences → Automatically check for updates. LakeDB requests public release metadata from the official GitHub repository and displays a banner when a newer compatible release exists. Use Help → Check for updates… for a manual check.

Stable versions ignore prereleases. Beta versions can discover newer betas or a later stable version. LakeDB uses only validated official LakeDB release and asset URLs, and it never downloads or installs an update without an explicit action.

Recover the multiconnection workspace

LakeDB saves connection workspace order, open SQL/table tabs, unsaved SQL, cursor/scroll positions, selected schemas, table view state and panel layout. Each connection keeps its context independently. State is saved after changes, when the page is hidden and during a normal shutdown.

An active-run marker distinguishes a clean exit from an unexpected process stop. On the next launch, LakeDB restores the latest safe session and tells you when the previous run ended unexpectedly. Query results, running-query state and passwords are never copied into the session snapshot.

Restore configuration safely

1. Choose File → Restore configuration….
2. Select a LakeDB configuration JSON file no larger than 10 MB.
3. Confirm the restore.
4. Keep the automatic before-restore-…json safety backup path shown by LakeDB.

The restore is validated and applied transactionally. Connections and preferences are merged; workspace SQL content and local SQL file paths are excluded. A password remains attached only if the destination identity—including TLS and SSH details—is unchanged.

Restore SQL safely

LakeDB checks the SQL file before reading it and validates the selected target. It exports a recovery dump of the target schema before executing the restore. If execution stops midway, the error points to that dump because database servers cannot guarantee a transaction across every DDL statement.

Always rehearse important restores with a non-production copy. A LakeDB recovery dump is a guardrail, not a replacement for independently tested backups.

Update older profiles

Local SQLite migrations run in version order and in individual transactions. Before pending migrations, LakeDB creates a pre-v…backup snapshot next to the local profile database. Automated tests upgrade an original v1 fixture through the current schema, reopen it and verify that connections, settings and session content remain intact.

If an update cannot start, preserve the profile directory and the pre-migration snapshot before reinstalling or filing a bug.

Verified in-app updates

From LakeDB 0.8.2 onwards, an update notification includes Download update as well as View release. LakeDB downloads the package for the current platform into Downloads/LakeDB Updates, shows live progress and verifies it against the SHA-256 file published with the release. Installation controls remain disabled until verification succeeds.

• Windows: select Open installer. LakeDB opens the normal verified NSIS setup and remains running, so setup stays visible and any installation problem can be reported. Complete setup, then restart LakeDB.
• macOS: select Open DMG, then replace LakeDB in Applications. Silent replacement requires the signed/notarized 1.0 distribution.
• Linux: select Launch AppImage to make the verified package executable, close LakeDB and start the new AppImage.

Downloads can be cancelled or retried. A checksum mismatch, incomplete transfer, unexpected package name or unofficial download URL is rejected.

LakeDB 0.8.0 and 0.8.1 only open the release page, so moving to 0.8.2 requires one final manual download. Windows builds 0.11.0 and 0.11.1 contain an experimental Restart and update action that can close LakeDB without completing setup. Upgrade those builds to 0.11.2 manually through View release once; later Windows updates use the visible flow above.

Beta signing notice

The current pre-1.0 beta does not yet use trusted distribution certificates. macOS packages have an ad-hoc integrity signature but are not Developer ID signed or notarized, while Windows packages remain unsigned. Gatekeeper or SmartScreen may therefore warn on first launch. Download only from the official Releases page and compare the SHA-256 checksum. Stable 1.0+ publication is configured to require trusted macOS/Windows signing and Apple notarization.