Technical requirements

Runtime

• Java 21 or later (JRE is enough to run BroadSQL; a JDK is only needed to build it).
• Windows is the primary, fully supported platform. BroadSQL also runs on Linux, but Linux support currently has some known rough edges.

Databases supported out of the box

BroadSQL ships with JDBC drivers for five databases: no extra download needed:

H2 is also the format BroadSQL itself uses for its own connections file (the CDF, $CDF), and one of the destination kinds the DUMP command can write to (see below).

Adding another database type

BroadSQL can connect to any JDBC-compliant database beyond the five bundled drivers listed above. Drop the vendor's JDBC .jar into the drivers/ folder (or lib/) next to the BroadSQL installation, then use SHOW DRIVERS; to confirm it was found: it scans both folders and lists every JDBC driver there (name, version, vendor; add DETAILED for the JAR path and driver class name(s)).

If a database type's driver class cannot be found on the classpath, CONFIG and ADD CONNECTION still let it be selected but mark it (driver not found) in the type list, and CONNECT reports a clear error naming the missing driver class until the matching jar is added and BroadSQL is restarted.

Behavior that differs by database type

A handful of commands and internal checks are implemented only for specific database types rather than through a generic, driver-agnostic mechanism:

• CHANGE PASSWORD only knows the password-change syntax for Oracle, MySQL, PostgreSQL, H2, and HSQL. It reports "Operation not supported" for every other connected database type, regardless of whether that database has its own equivalent SQL statement.
• LINK TABLE only works when the current connection is H2: it runs H2's own CREATE LINKED TABLE statement there, which has no equivalent in most other databases. The connection the table is linked from can be of any type whose JDBC driver BroadSQL has (H2, HSQLDB, PostgreSQL, or a driver added to drivers/).
• Rollback of DDL statements (CREATE/ALTER/DROP/TRUNCATE) after an uncommitted change is handled correctly for a known list of database types (Derby, SQLite, PostgreSQL, SQL Server, Sybase, DB2, Informix, Firebird; databases where DDL does not force an implicit commit) and for Oracle and H2 (which BroadSQL can query directly for pending uncommitted transactions). For any other database type, HSQLDB included, BroadSQL tracks uncommitted-transaction state internally, which is less precise than asking the database directly. With Autocommit off, closing a connection (DISCONNECT, switching connection, leaving BroadSQL) always rolls back pending changes and never commits them; if the database cannot say whether changes are pending (for example an Oracle account without access to DBMS_TRANSACTION), BroadSQL warns, rolls back and closes the connection normally.

None of this affects ordinary SELECT/INSERT/UPDATE/DELETE/DDL statements, table/column browsing (DESCR, SHOW TABLES, etc.), or DUMP <table> alone: those work the same way regardless of database type, for any database reachable through a registered connection.

DUMP (export to a file, a spreadsheet, or H2)

DUMP (and its compatibility alias PULL) can read from any currently connected database type: there is no restriction on the source. Its destination is a local H2 database (AS H2), a tab of an Excel/ODS spreadsheet (AS XLSX/AS ODS), or a whole file (AS CSV/AS TEXT/AS JSON/AS MD/AS HTML).

Regardless of destination, only "ordinary business data" column types can be exported: text, integers, decimals, floating point, boolean, and date/time/timestamp columns. Large objects (BLOB/CLOB/ NCLOB), binary data, and structural or vendor-specific types (arrays, structs, XML, etc.) are rejected with an explicit error rather than silently dropped or corrupted, see Export for the full command reference.

Configuration

Once BroadSQL runs, one settings file decides how it behaves on your computer: conf/BroadSQL.ini on Windows, conf/broadsqlux.ini on Linux. It sets where exports are written and in which format by default, the CSV separator, the Scripts Library folder, the console's colors and history, the activity log, and the proxy used for APIs. The defaults work out of the box, but the export folder and the log folder usually deserve a look before real work. Every setting is described in Application settings.