macOS - Software Lifecycle - Uninstall DBeaver Community

What the DBeaver Community uninstaller does

This Automox Worklet™ removes DBeaver Community, the open-source universal database tool from DBeaver Corp, from macOS endpoints. The Worklet inspects /Applications for the DBeaver.app bundle, deletes the application package when it is present, and clears the DBeaverData support directory under ~/Library/Application Support so the next reinstall starts clean. DBeaver Community ships SQL editors and drivers for MySQL, PostgreSQL, Oracle, Microsoft SQL Server, MongoDB, and dozens of other engines, which is exactly why an unmanaged copy on a Mac becomes a data access problem.

The evaluation script tests for the directory /Applications/DBeaver.app. If the bundle is present, the endpoint is flagged non-compliant and remediation is scheduled. Remediation runs rm -rf /Applications/DBeaver.app to remove the application, then rm -rf on ~/Library/Application Support/DBeaverData for every interactive user. That second step clears cached credentials, saved connection profiles, and driver downloads so nothing lingers on the disk.

The Worklet targets DBeaver Community specifically. DBeaver Pro, DBeaver Enterprise Edition, and other database IDEs such as TablePlus, DataGrip, or Sequel Pro install under different bundle identifiers and are left untouched. The script does not force-quit a running DBeaver session, so schedule the policy during a maintenance window or pair it with a companion Worklet that closes the application before removal.

Why remove DBeaver Community from macOS endpoints

An unmanaged database client on a corporate Mac broadens the data-egress surface any cached production credential can reach. DBeaver Community drives raw SQL against any reachable database server with cached connections, saved query history, and bulk export to CSV or JSON. When a developer installs it to debug a one-off issue and then leaves the team, the binary stays behind and so does the connection profile pointing at production. Auditors evaluating SOC 2 CC6.1 logical access controls or PCI-DSS 7.1 least-privilege requirements flag exactly this pattern, and the only durable fix is removing the client from the endpoint rather than rotating credentials forever.

Scheduling this Worklet against the Mac group walks every endpoint at evaluation time, locates the /Applications/DBeaver.app bundle and any ~/Library/DBeaverData footprint, and removes both under the Automox agent's root context. The offboarded developer's MacBook, the shared QA Mac mini, and the unattended kiosk on the engineering floor converge on the same baseline by the next evaluation window, with per-host exit codes in the activity log as audit evidence.

How DBeaver Community removal works

1. Evaluation phase: The Worklet runs a shell check against /Applications/DBeaver.app. If the directory exists, the script exits non-zero and Automox marks the endpoint non-compliant. If the bundle is absent, the script exits 0 and no remediation is scheduled. Because the check is a single file system test, the evaluation is cheap to run on a recurring policy across thousands of Macs.

2. Remediation phase: The Worklet runs rm -rf /Applications/DBeaver.app to delete the application bundle. It then iterates the /Users directory and runs rm -rf on ~/Library/Application Support/DBeaverData for every home directory it finds. This removes the workspace database, cached driver downloads, saved connection profiles, and the .dbeaver-data-sources.xml credential cache. The script logs each path it touches to stdout for the Automox Activity Log. It then re-tests /Applications/DBeaver.app and exits 0 on success, or non-zero if the bundle is still present (typically because a user has DBeaver open and macOS holds the binary file handle).

DBeaver Community removal requirements

• macOS 10.12 (Sierra) or later, including macOS 14 (Sonoma) and macOS 15 (Sequoia) on Apple Silicon and Intel hardware

• Automox agent installed and running with root privileges (the default agent context already meets this)

• DBeaver Community installed at /Applications/DBeaver.app (the standard install location for the .dmg and Homebrew cask dbeaver-community)

• No active DBeaver process holding a file handle on the bundle; pair this Worklet with a pre-step that runs pkill -f DBeaver if your fleet runs it during business hours

• Awareness that this Worklet does not remove DBeaver Pro, DBeaver Enterprise Edition, or community editions installed under a non-default path; author a sibling Worklet if those variants are in scope

Expected state after DBeaver Community removal

After a successful run, /Applications/DBeaver.app is gone, Spotlight no longer surfaces DBeaver as an installed application, and ls ~/Library/Application Support/DBeaverData returns No such file or directory for every user account on the Mac. Launching DBeaver from a Dock icon or alias fails with a missing-application error, and the next Automox evaluation reports the endpoint as compliant without applying remediation again. The .dbeaver-data-sources.xml connection file under DBeaverData is removed along with the workspace, so cached credentials cannot be recovered without restoring from a Time Machine snapshot.

Validate the outcome by running ls /Applications/DBeaver.app (expect a No such file or directory error) and mdfind "kMDItemCFBundleIdentifier == 'org.jkiss.dbeaver.core.product'" (expect no results). For audit evidence, capture the Automox Activity Log entry for the policy run – the log lines list every path the remediation deleted, which satisfies most SOC 2 and PCI-DSS evidence requests for software-removal events. If the Worklet exits non-zero, the most common cause is a logged-in user with DBeaver open; rerun the policy after the next reboot or schedule it inside a maintenance window.