Security and Privacy

Security and Privacy

Local by default

LakeDB currently has no telemetry, ads or cloud synchronization. Connections and queries are not sent to a LakeDB service. Large results remain temporarily in memory and are excluded from session snapshots.

Credentials and application boundary

Saved passwords use AES-256-GCM in a separate SQLite table. The local key is stored with restricted permissions. This protects against casual database-file inspection, but anyone controlling your operating-system account and both files could recover secrets; protect your user account, disk and backups.

The renderer has no direct Node.js, filesystem, SQLite, credential or MySQL socket access. Every operation crosses a narrow validated API in Electron's main process. External navigation, unexpected windows and unrequested permissions are blocked.

Configuration restore accepts only a bounded, versioned LakeDB JSON format. Restored credentials are bound to the original destination identity and are cleared if host, user, TLS or SSH details change. Update links are restricted to official LakeDB GitHub release pages.

Release CI uses pinned GitHub actions. The public 0.7 beta is deliberately unsigned; stable tags are blocked unless macOS signing, Apple notarization and Windows signing secrets are present. Every artifact includes a SHA-256 checksum.

Dangerous SQL

LakeDB conservatively analyzes SQL and confirms operations such as DELETE/UPDATE without WHERE, DROP, TRUNCATE and destructive ALTER. Production actions require a typed confirmation. These safeguards reduce mistakes, but never replace least-privilege database users, reviewed migrations and verified backups.

Review and sanitize diagnostics before sharing them publicly.