SQL Workbench/J: Free Multi-Database Client for a Linux VPS

Command-line clients like psql and the MySQL shell handle a quick query fine, but they start to strain once a Linux VPS admin is juggling more than one database engine, or wants to browse table structures and query history without re-learning another tool's dialect for every server. SQL Workbench/J exists for exactly that gap: a free, Java-based SQL client that talks to any database with a JDBC driver — PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, and dozens more — through one consistent interface. This guide installs it, adds a JDBC driver, and points it at a database running on a remote Linux VPS.

What SQL Workbench/J Is

SQL Workbench/J is a free SQL query and browsing tool written in Java, which is the reason it runs identically on Linux, Windows, and macOS from the same download — the same client that manages a MySQL database on one VPS can open a Postgres connection to another with no separate install. It is deliberately DBMS-independent: rather than shipping built-in support for one vendor's database, it connects through JDBC and expects you to supply the driver for whatever engine you're actually talking to. That design keeps the core tool small and means it stays useful no matter which database engines you run across your fleet of servers.

The project has kept moving since its early releases — development, issue tracking, and releases are now hosted on Codeberg, a community-run, non-commercial code-hosting platform, rather than a single commercial vendor's infrastructure. For a VPS admin evaluating whether a free tool is worth relying on, that's a reasonable signal: it's still an active project, not an abandoned download from a decade ago.

Because it's a desktop GUI application, the practical setup for a VPS admin usually isn't "run it on the server." A bare Linux VPS has no desktop environment by default, and adding one just to run a SQL client is overkill. The more common pattern — and the one this guide follows — is installing SQL Workbench/J on your own Linux, Windows, or macOS workstation, then connecting outward to the database that lives on the VPS.

Installing SQL Workbench/J on Linux

The client requires a Java runtime to be present on whichever machine you install it on — the tool itself does not bundle a JVM, so confirm one is already available before downloading anything:

1java -version

If that returns nothing, install a current OpenJDK package for your distribution first (apt install default-jre on Debian/Ubuntu, or the equivalent for your distro) before continuing. The installation instructions in the project manual cover this requirement along with the platform-specific packages available — there's a generic package that works on any system with Java installed, which is the one to reach for on Linux.

Once Java is confirmed, download the generic package and unpack it into a directory of your choosing:

1mkdir -p ~/sqlworkbench
2cd ~/sqlworkbench
3unzip Workbench-Build*.zip

The archive extracts a set of files including sqlworkbench.sh, the launcher script for Unix-like systems. Make it executable and start the client:

1chmod +x sqlworkbench.sh
2./sqlworkbench.sh

That launches the GUI. If you want a permanent desktop shortcut on a Linux workstation, create a .desktop entry pointing at the script rather than re-running it from a terminal each time — the manual's installation page walks through the platform-specific options if you need something more than a plain shell launch.

Adding a JDBC Driver

SQL Workbench/J ships with no drivers included, which is the trade-off for staying DBMS-independent — you supply the driver for whichever database you're connecting to. For a database running on your VPS, that means downloading the JDBC driver JAR published by that database's project (for example, the PostgreSQL JDBC driver or MySQL's Connector/J) and pointing SQL Workbench/J at it.

Inside the application, open the driver management dialog — reachable from the connection window — and add a new entry: give it a name, browse to the downloaded JAR file, and the client will typically detect the correct driver class automatically once the JAR is selected. The JDBC setup page in the manual documents this driver-registration step along with the connection-profile fields that follow, and is worth keeping open the first time through since the exact dialog layout is easier to follow with the screenshots in front of you.

You only need to register a given driver once per machine — after that, it's available to any connection profile that needs it, so adding a second database of the same type later is just a matter of creating a new profile that reuses the existing driver entry.

Defining a Connection Profile to Your VPS Database

With the driver registered, create a connection profile: a saved set of credentials and connection details you can reopen without re-entering everything. A profile needs the registered driver selected from a dropdown, a JDBC URL in the form appropriate to that database (a Postgres URL looks like jdbc:postgresql://<host>:<port>/<database>; MySQL's equivalent follows the same pattern with jdbc:mysql://), and the username and password for the database account you're connecting with. Save the profile under a name you'll recognize later — "prod-vps-postgres" beats "New profile" the third time you're switching between servers.

The manual's JDBC setup page covers the full set of profile options, including autocommit behavior and driver-specific connection properties, which vary slightly by database engine.

Reaching the Database Securely from Off-Server

The one detail worth getting right before you type a real password into a connection profile: a database port sitting open to the public internet is a liability, and most VPS database setups shouldn't expose PostgreSQL's 5432 or MySQL's 3306 directly. The standard fix is an SSH tunnel — you already have SSH access to administer the VPS, so use that same access to forward the database port through it instead of opening a new one:

1ssh -L 5432:localhost:5432 user@your-vps-ip

With that tunnel running, point the connection profile's JDBC URL at localhost instead of the VPS's public IP — jdbc:postgresql://localhost:5432/dbname — and the traffic travels through the encrypted SSH session rather than a bare, publicly reachable port. The -L flag and the rest of ssh's forwarding options are documented in the OpenSSH client manual page. A firewall rule restricting the database port to a specific known IP is a reasonable alternative if you'd rather not keep a tunnel open, but the tunnel approach means the port never needs to be opened at all.

Working With the Tool Day to Day

Once a profile connects, the working layout is a SQL editor pane for writing and running statements, a results grid below it, and a database object browser down the side for looking through schemas, tables, and columns without writing a query first. JDBC — the Java standard this whole tool is built on — is what makes that browser possible across engines: the same metadata calls work whether the connection is to Postgres or MySQL, so the tool doesn't need engine-specific code to show you what's in a database. Results can be exported to common formats like CSV directly from the grid, useful for pulling a quick dataset out of a VPS-hosted database without writing a separate export script.

Multiple connection tabs let you have profiles for several servers open side by side, which is the actual payoff of the multi-database design: one client window, several databases, no context-switching between vendor-specific tools.

Who This Tool Is Best For

Good fit:

• VPS admins running more than one database engine across their servers and tired of switching tools
• Anyone who wants a lightweight GUI client without installing a full commercial database IDE
• Situations where a database has no web-based admin panel and the only path in is JDBC over an SSH tunnel

Not the best fit:

• Teams fully committed to one engine's native tool, where a Postgres-only or MySQL-only client already covers everything
• Anyone who specifically wants browser-based access with nothing installed locally

Pros and Cons

Pros

• Free to download and use, with no bundled driver bloat
• Works identically on Linux, Windows, and macOS since it's Java-based
• One client for any JDBC-reachable database, instead of a separate tool per engine
• Actively maintained, with development now hosted on Codeberg

Cons

• Requires manually sourcing and registering a JDBC driver JAR for each database engine yourself
• A desktop GUI application — not something you'd run directly on a headless VPS without a desktop environment
• Interface favors function over modern polish compared to some commercial database IDEs

Final Verdict

For a Linux VPS admin who touches more than one database engine, SQL Workbench/J earns its place with a straightforward trade: a short setup involving a Java runtime, a driver JAR, and a connection profile, in exchange for one consistent SQL client instead of a different tool per server. Route the connection through an SSH tunnel rather than opening the database port directly, and it's a solid, no-cost addition to a VPS admin's toolkit — just don't expect it to run comfortably as a headless service on the server itself.

References

• SQL Workbench/J — the project home, for what the tool is and its licence
• Installing SQL Workbench/J — the Java runtime requirement and the platform packages
• JDBC driver setup — adding a driver JAR and defining a connection profile
• Codeberg — where the project's development, issues and releases are now hosted
• ssh(1) — OpenSSH client manual page
• JDBC Overview — Oracle Java Tutorials