Install DBeaver on Ubuntu 26.04 / 24.04 and Debian 13

DBeaver Community is a free desktop SQL client that talks to PostgreSQL, MySQL, MariaDB, SQLite, Oracle, SQL Server and well over a hundred other databases over JDBC. On Ubuntu and Debian it ships its own Java runtime, so there’s no JDK to install first. Use DBeaver’s own APT repository, because that gives you the same package as the download page and apt upgrade keeps it current.

Original content from computingforgeeks.com - post 5352

This guide covers that repository on Ubuntu 26.04, Ubuntu 24.04 and Debian 13, then the direct .deb, Snap and Flatpak options with their real disk cost. After that you’ll connect to a PostgreSQL server that only listens on localhost, through an SSH tunnel with a passphrase-protected key. Every command below was run, and every screenshot taken, with DBeaver Community 26.2.3 on Ubuntu 26.04 and 24.04 lab VMs and a Debian 13 database server in October 2026.

Pick an install method

All four methods install the same release, and they differ in how updates arrive and how much disk they take. We measured the numbers in this table on clean VMs, so they include whatever each method had to pull in on top of DBeaver itself. That is the fair comparison for a new workstation, because nobody installs a SQL client onto a machine that already carries the exact runtimes it wants.

Method	Updates	Disk used in the lab	Notes
DBeaver APT repository	With apt upgrade	206 MB	Recommended. Bundled Java runtime, no extra packages
Direct .deb download	Manual, download each release again	206 MB	Same package, no repository behind it
Snap (dbeaver-ce)	Automatic, by snapd	240 MB snap file	Classic confinement, so it reads your SSH keys normally
Flatpak (Flathub)	With flatpak update	2.8 GB on a fresh system	Pulls the GNOME runtime, GL drivers and codecs the first time

Flatpak only looks expensive on a machine that has never used it, and ours was one of those. If you already run other GNOME Flatpak apps the runtime is shared and the app itself is 312.6 MB. For everyone else the APT repository is the lighter and simpler choice, because it adds one package and one source file and then rides along with the updates you already run. It is what the rest of this guide uses.

Add the DBeaver APT repository

DBeaver signs its repository with an ASCII-armored key, and APT can read that file directly. You do not need gpg --dearmor, which matters on Debian 13 cloud and minimal images because they don’t ship gpg at all. Ubuntu Desktop has the opposite gap and leaves out curl, so install it first, then save the key under /etc/apt/keyrings:

sudo apt install -y curl
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://dbeaver.io/debs/dbeaver.gpg.key -o /etc/apt/keyrings/dbeaver.asc

The repository is a flat one, so the source file uses Suites: / and no Components line. Write it in the deb822 format that Ubuntu 24.04 and later use for their own sources:

printf '%s\n' 'Types: deb' 'URIs: https://dbeaver.io/debs/dbeaver-ce' 'Suites: /' 'Signed-By: /etc/apt/keyrings/dbeaver.asc' | sudo tee /etc/apt/sources.list.d/dbeaver.sources

Refresh the package index and confirm APT sees the package from the new source:

sudo apt update
apt policy dbeaver-ce

Expect the candidate to come from dbeaver.io with the current release number:

dbeaver-ce:
  Installed: (none)
  Candidate: 26.2.3
  Version table:
     26.2.3 500
        500 https://dbeaver.io/debs/dbeaver-ce  Packages

Now install it. The download is about 128 MB:

sudo apt install dbeaver-ce

APT puts everything in /usr/share/dbeaver-ce, including a private Java runtime in the jre folder, and adds dbeaver and dbeaver-ce launchers to /usr/bin plus a desktop entry in /usr/share/applications. No system Java or other package comes with it, so removing the package later leaves no stray JDK behind. Check the installed version and the bundled Java:

dpkg -s dbeaver-ce | grep -E '^(Version|Installed-Size)'
/usr/share/dbeaver-ce/jre/bin/java -version

On the Ubuntu 26.04 VM the output was:

Installed-Size: 208045
Version: 26.2.3
openjdk version "25.0.4.1" 2026-08-18 LTS
OpenJDK Runtime Environment Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS, mixed mode)

Ubuntu 24.04 and Debian 13 gave the same version with the same steps. Because DBeaver uses its bundled runtime, whatever Java you have installed for other work, or none at all, makes no difference to it, and an OpenJDK upgrade elsewhere on the box cannot break it. Future releases arrive with your normal sudo apt update && sudo apt upgrade.

Install the .deb, Snap or Flatpak instead

We installed and checked each of these on the Ubuntu 24.04 VM. Use one of them only if the repository does not suit you, and do not stack two methods on one machine. Each one keeps its own workspace, so the .deb uses ~/.local/share/DBeaverData, the Snap uses ~/snap/dbeaver-ce/<revision>/.local/share/DBeaverData, and the Flatpak uses ~/.var/app/io.dbeaver.DBeaverCommunity/data/DBeaverData. Two installs mean two app grid entries with two separate sets of connections, which is confusing fast.

Direct .deb download

DBeaver keeps a stable link that always points at the newest Linux .deb on GitHub, so you never have to look up a release number. Download it and let APT install the local file:

wget https://dbeaver.io/files/dbeaver-ce_latest_amd64.deb
sudo apt install ./dbeaver-ce_latest_amd64.deb

It’s the same package, but apt policy now shows it coming only from /var/lib/dpkg/status. Nothing will tell you about the next release, so you repeat the download every time. The package also declares no dependencies, which becomes important if you try this on a server, as the troubleshooting section below shows.

Snap

DBeaver publishes the Snap itself with classic confinement, so it runs without the usual snap sandbox and can open your private key from ~/.ssh for the tunnel later in this guide. Its workspace is the exception, because the Snap points Java’s home directory at the snap’s own data folder. When we launched it, DBeaver created its data under ~/snap/dbeaver-ce/569/.local/share/DBeaverData, not in the .deb’s location:

sudo snap install dbeaver-ce --classic
snap list dbeaver-ce

On test day the stable channel carried the same release as the repository:

Name        Version  Rev  Tracking       Publisher     Notes
dbeaver-ce  26.2.3   569  latest/stable  dbeaver-corp  classic

snapd refreshes installed snaps automatically in the background, so new DBeaver releases arrive without any command from you. Run sudo snap refresh dbeaver-ce when you want a new release straight away instead of waiting for the next scheduled check.

Flatpak

Ubuntu doesn’t ship Flatpak by default, so install it and add Flathub before pulling the app. The Snap, Flatpak and APT guide for Ubuntu 26.04 covers that setup in more depth if you plan to use Flatpak for other apps too.

sudo apt install flatpak
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install flathub io.dbeaver.DBeaverCommunity

On the fresh VM this pulled the GNOME runtime, the GL drivers and the codec extension along with the app, and /var/lib/flatpak grew to 2.8 GB. The app’s own permissions include your home directory and the SSH agent socket, so key-based tunnels work from inside the sandbox. Check both with flatpak info:

flatpak info io.dbeaver.DBeaverCommunity | grep -E 'Version|Runtime|Installed'
flatpak info --show-permissions io.dbeaver.DBeaverCommunity

The relevant lines on the lab VM:

     Version: 26.2.3
   Installed: 312.6 MB
     Runtime: org.gnome.Platform/x86_64/51
[Context]
shared=network;ipc;
sockets=wayland;pulseaudio;fallback-x11;ssh-auth;
devices=dri;
filesystems=home;

Updates come with sudo flatpak update, which refreshes the app and the shared runtimes together. Remember that this copy keeps its own workspace. On first launch the Flathub wrapper copies an existing ~/.local/share/DBeaverData into it, so you start with your .deb connections, but the two copies drift apart from then on.

Launch DBeaver and finish the first-run setup

Open DBeaver from the app grid, or run dbeaver & from a terminal on the desktop session. The first start opens a Product Configuration wizard with five pages, and nothing on them is permanent because Help, Product Configuration brings the wizard back later:

1. Configure DBeaver, for the interface language
2. Appearance, for the theme and navigator view
3. Features, for AI integration and database dashboards
4. Data collection, for anonymous usage statistics
5. Final steps, for the sample database and tips

Click Next through the pages and stop at Data collection. Sharing anonymous usage statistics is selected by default, and the page says it sends your OS, locale, the features you use and the database types you connect to. That is harmless on a personal laptop, but a workstation that connects to client databases is a different story, so pick Do not share before you continue.

The last page offers the SQLite sample database and Tip of the day. Keep the sample if you want something to click around in, then press Apply. The main window opens with the database navigator on the left and the sample connection already listed:

Everything DBeaver writes for your account lives in ~/.local/share/DBeaverData, split into three folders that matter:

• workspace6, with connections and SQL scripts
• drivers, with the JDBC jars it downloads
• install-data, with the startup error logs

Back the folder up once you have more than a handful of connections, because a new machine starts with an empty one and recreating tunnels by hand is slow. The package never writes there, so upgrades and even a purge leave it alone, as the removal section below shows.

Connect to PostgreSQL through an SSH tunnel

A production database should not listen on a public interface, and the one in this lab doesn’t. PostgreSQL on db01 runs on Debian 13 with the stock listen_addresses = 'localhost', so port 5432 is closed to the network:

sudo ss -ltnp | grep 5432

Only the loopback addresses appear:

LISTEN 0      200        127.0.0.1:5432      0.0.0.0:*    users:(("postgres",pid=18267,fd=7))
LISTEN 0      200            [::1]:5432         [::]:*    users:(("postgres",pid=18267,fd=6))

DBeaver reaches it by opening an SSH session to db01 and forwarding a local port to 127.0.0.1:5432 on the far side. In our lab log the forward listened on 127.0.0.1:18996 on the desktop, so nothing new was exposed on either machine. You need SSH access to the server as a normal user for this, and a key beats a password because DBeaver can reuse it without storing a server password. Create one on the desktop and give it a passphrase when ssh-keygen asks:

ssh-keygen -t ed25519 -C "josphat@ws01"

Copy the contents of ~/.ssh/id_ed25519.pub into ~/.ssh/authorized_keys for your user on the database server. If you haven’t set up keys on that box before, the SSH key authentication guide for Ubuntu 26.04 walks through it, including turning password logins off afterwards. The database itself needs a login role and a database, which the PostgreSQL on Debian guide shows; the lab uses a role called appuser that owns a database called inventory.

In DBeaver press Shift+Ctrl+N to open Connect to a database. Type postgres in the search box, select PostgreSQL and click Next, then keep the standard PostgreSQL driver on the next page:

On the Main tab, leave Host as localhost and Port as 5432. That looks wrong until you remember these values are resolved on the SSH server once the tunnel is up, so localhost here means the database server’s own loopback. Fill in the database name, username and password:

Now open the SSH, SSL drop-down at the top right of the tabs and choose SSH. The new tab needs five values, and these are the ones we used:

• Host/IP: db01, port 22
• User Name: your SSH login, josphat here
• Authentication Method: Public Key
• Private Key: /home/josphat/.ssh/id_ed25519
• Passphrase: the one you gave ssh-keygen

Click Test tunnel configuration before anything else. It checks only the SSH leg, so a failure here is about the key, the user or the firewall and not the database, which halves the places you have to look. The default SSHJ client accepted the passphrase-protected ed25519 key in the current OpenSSH format without any conversion:

Then click Test Connection. The first time you use a database type, DBeaver offers to download its JDBC driver from Maven Central. Expand Show details if you want to see the exact jars, then click Download:

Downloaded jars go into ~/.local/share/DBeaverData/drivers/maven/maven-central. A workstation without internet access cannot fetch them, and the dialog itself names the fallback, which is to obtain the driver files yourself and add them in the driver editor. Once the download finishes the test runs through the tunnel and reports the server and driver versions:

Those 51 seconds include the driver download. Reconnecting after a restart took about 1.3 seconds in DBeaver’s log, tunnel included. Click Finish and the connection appears in the navigator as inventory with db01:5432 beside it.

DBeaver stores the connection in data-sources.json inside the workspace. The tunnel settings sit under handlers, with the key path but no secrets:

python3 -m json.tool ~/.local/share/DBeaverData/workspace6/General/.dbeaver/data-sources.json

We trimmed the lab file to the tunnel block, which is the part that matters:

                "handlers": {
                    "ssh_tunnel": {
                        "type": "TUNNEL",
                        "enabled": true,
                        "save-password": true,
                        "properties": {
                            "jumpServer.count": 0,
                            "host": "db01",
                            "port": 22,
                            "authType": "PUBLIC_KEY",
                            "keyPath": "/home/josphat/.ssh/id_ed25519",
                            "implementation": "sshj",

Saved passwords and the key passphrase go into credentials-config.json next to it. The file isn’t plain text, but in Community Edition it is encrypted with a fixed key that is compiled into DBeaver’s open source code, so anyone who can read the file can decrypt it. DBeaver’s security docs reserve proper secure storage for database credentials to the paid editions. On a shared or unmanaged machine, untick Save password and DBeaver will ask for it each time you connect.

Run a query and read the results

Select the inventory database in the navigator and press Ctrl+] to open a SQL editor bound to it. The lab database has a products table and an orders table, so this query lists the top sellers over the last 30 days:

SELECT p.sku, p.name, sum(o.qty) AS units,
       round(sum(o.qty * p.price), 2) AS revenue
FROM orders o
JOIN products p ON p.id = o.product_id
WHERE o.ordered_at > now() - interval '30 days'
GROUP BY p.sku, p.name
ORDER BY revenue DESC
LIMIT 20;

Press Ctrl+Enter with the cursor inside the statement. A result grid opens under the editor, and the status line shows 20 rows fetched in 0.049 s against an orders table of 200,000 rows. The tunnel adds very little here because only the 20 result rows cross it, so keep the heavy lifting in SQL and let DBeaver fetch the answer, not the raw table:

Autocomplete opens while you type and can insert a suggestion you didn’t want, so paste longer queries or dismiss the list with Escape. Results stay in the grid until you close the tab, and the Export data button under it saves them to a file without running the query again.

If you mostly work with PostgreSQL and want a browser-based tool instead, pgAdmin 4 on Ubuntu is the other common choice. For a quick local MariaDB to point DBeaver at, the MariaDB on Ubuntu 26.04 guide gets one running in a few minutes.

Fix DBeaver install and launch errors

These are the two failures we hit in the lab, with the exact messages and what fixed them.

“Failed to load swt-pi3” on a server

Installing DBeaver on Ubuntu Server or a minimal Debian 13 server and running dbeaver over SSH prints this and exits:

SWT OS.java Error: Failed to load swt-pi3, loading swt-pi4 as fallback.
Dbeaver:
An error has occurred. See the log file
/home/josphat/.local/share/DBeaverData/install-data/org.jkiss.dbeaver.product/26.2.3-202610181708/1792704009684.log.

DBeaver’s log names the real cause, a missing GTK 3 library. Here is the same line from the Debian 13 server, with the long cache path shortened to the file name:

Caused by: java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
libswt-pi3-gtk-4974r10.so: libgtk-3.so.0: cannot open shared object file: No such file or directory

Because the .deb declares no dependencies, APT never pulls GTK onto a machine without a desktop. Installing the library is enough for DBeaver to start, which we confirmed under a virtual X display on the Ubuntu 24.04 server. GTK plus xvfb for that test came to 93 packages and 376 MB:

sudo apt install libgtk-3-0t64

Even so, a server is the wrong place for a desktop SQL client. GTK and the dozens of libraries it pulls in become one more set of packages to patch on a box that never shows a screen, and you still need X forwarding or a virtual display to see the window. Run DBeaver on your workstation and reach the server’s database through the SSH tunnel shown above, which keeps the database port closed and the GUI stack off the server.

“sudo: gpg: command not found” on Debian 13

The instructions on the DBeaver download page pipe the key through gpg --dearmor. On a Debian 13 cloud image that fails, because gpg isn’t installed, and the next apt update then rejects the repository. The lab wrote the key to /etc/apt/keyrings/dbeaver.gpg; if you followed the download page, the path in your error is /usr/share/keyrings/dbeaver.gpg.key. These are the key lines, with the long warning shortened:

sudo: gpg: command not found
W: OpenPGP signature verification failed: https://dbeaver.io/debs/dbeaver-ce  InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Error: Failed to parse keyring "/etc/apt/keyrings/dbeaver.gpg"
E: The repository 'https://dbeaver.io/debs/dbeaver-ce  InRelease' is not signed.

Save the armored key as /etc/apt/keyrings/dbeaver.asc and point Signed-By at it, exactly as in the repository section. Debian 13’s sqv verifier and APT on Ubuntu both read the .asc file directly, and the same install then went through with no other change.

Remove DBeaver

Purge the package, then delete the source file and the key so apt update stops checking the repository:

sudo apt purge dbeaver-ce
sudo rm -f /etc/apt/sources.list.d/dbeaver.sources /etc/apt/keyrings/dbeaver.asc

Snap and Flatpak removal can delete your connections, so copy their workspace folder somewhere safe first if you want to keep them. sudo snap remove --purge dbeaver-ce deletes ~/snap/dbeaver-ce with the workspace inside it and takes no snapshot, which we confirmed on the lab VM; drop --purge and snapd keeps an automatic snapshot instead. For the Flatpak, sudo flatpak uninstall io.dbeaver.DBeaverCommunity followed by sudo flatpak uninstall --unused removes the app and its runtimes, which took /var/lib/flatpak from 2.8 GB back to 4.9 MB in the lab. Its workspace in ~/.var/app/io.dbeaver.DBeaverCommunity stays until you delete it.

The APT purge does not touch ~/.local/share/DBeaverData, which was 2.6 MB on the test VM afterwards. If you added the per-user launcher from the heap section below, delete ~/.local/share/applications/dbeaver-ce.desktop too, or a dead DBeaver icon stays in the app grid. Keep it if you plan to reinstall and want your connections back, because the next install picks it up as is. Delete it with rm -rf ~/.local/share/DBeaverData when the machine is leaving your hands, since it still holds saved credentials and the drivers DBeaver downloaded.

Raise the heap so upgrades keep it

DBeaver starts its JVM with -Xmx1024m, set in /usr/share/dbeaver-ce/dbeaver.ini. One gigabyte is fine for browsing tables, but large result sets and big exports are where it runs short. The usual advice is to edit that file, and that change does not last. The file is not a dpkg conffile, so every upgrade or reinstall writes the stock value back. On a repository install you can watch it happen:

dpkg-query -W -f='${Conffiles}\n' dbeaver-ce
sudo sed -i 's/^-Xmx1024m$/-Xmx2048m/' /usr/share/dbeaver-ce/dbeaver.ini
sudo apt install --reinstall dbeaver-ce
grep -E '^-Xm' /usr/share/dbeaver-ce/dbeaver.ini

Nothing is listed as a conffile, and after the reinstall the edit is gone:

-Xms64m
-Xmx1024m

Put the setting in a per-user launcher instead, which the package never touches. Copy the desktop entry into your own applications folder and change its Exec line:

mkdir -p ~/.local/share/applications
cp /usr/share/applications/dbeaver-ce.desktop ~/.local/share/applications/
sed -i 's|^Exec=.*|Exec=env NO_AT_BRIDGE=1 /usr/share/dbeaver-ce/dbeaver --launcher.appendVmargs -vmargs -Xmx2048m|' ~/.local/share/applications/dbeaver-ce.desktop

The --launcher.appendVmargs flag is not optional. With plain -vmargs, the launcher replaces the JVM options from dbeaver.ini instead of adding to them, and the test JVM came up with none of the 22 --add-opens flags that DBeaver ships. With the append flag, both -Xmx values are passed and the later one wins. The sed keeps the stock NO_AT_BRIDGE=1 setting and drops %U, because anything after -vmargs goes to the JVM. Quit DBeaver completely first, since a second launch hands over to the running instance and keeps its old heap. Then start it from the app grid and ask the running JVM for its limit with the bundled jcmd:

/usr/share/dbeaver-ce/jre/bin/jcmd $(pgrep -f '[d]beaver-ce/jre/bin/java') VM.flags | tr ' ' '\n' | grep -E '^-XX:MaxHeapSize'

A 2 GB heap shows up as 2147483648 bytes, and DBeaver’s own startup log reports “Memory available 64Mb/2048Mb”:

-XX:MaxHeapSize=2147483648

Size it to the result sets you actually pull and leave most of the RAM to the rest of the desktop. Doubling the default to 2 GB is a sensible first step, because you can check the effect with the same jcmd line after every change. With the repository handling upgrades and the heap set per user, you shouldn’t need to revisit this install until you change machines. If you also run Fedora workstations, the DBeaver on Fedora guide covers the RPM and Flatpak side, and the SSH tunnel guide shows the same port forward from the command line when you need it outside DBeaver.