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 four databases: no extra download needed:

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

SHOW DRIVERS; lists these four drivers with the source Bundled, and every driver you added with the source drivers folder.

Bundled, validated and external drivers

BroadSQL distinguishes three levels of support for a database driver:

A driver is bundled only while its project is actively maintained, works with the supported Java version, may be redistributed, and is tested by BroadSQL. A driver whose project stops being maintained leaves the bundled set; you can still install it yourself as an external driver.

Apache Derby

The Apache Derby project was retired in October 2025: it is read only and publishes no new release or fix. Since BroadSQL 5.5.5, Derby is no longer included in BroadSQL and is not part of the databases BroadSQL maintains and tests.

• Your Derby connections are kept. They stay in the CDF with their type (DERBY Embedded or DERBY Client), URL and password. Until a Derby driver is installed, CONNECT says that the driver class org.apache.derby.iapi.jdbc.AutoloadedDriver (or org.apache.derby.client.ClientAutoloadedDriver) was not found.
• To keep using Derby, download a Derby release at your own discretion from the Apache Derby downloads (10.17 for Java 21) and copy into the drivers folder: derby.jar and derbyshared.jar for an embedded database, derbyclient.jar and derbyshared.jar for a Derby network server. Restart BroadSQL, then check with SHOW DRIVERS;.
• Best effort only: Derby then works like any external database, through the standard JDBC mechanism. BroadSQL gives no Derby-specific guarantee.
• SET PASSWORD no longer changes Derby passwords: change them with Derby's own tools, then update the password BroadSQL saved with EDIT CONNECTION.
• Derby writes its derby.log file in the folder BroadSQL is started from (BroadSQL no longer moves it to logs).

Adding another database type

BroadSQL can connect to any JDBC-compliant database beyond the four bundled drivers listed above. For the steps, the URL format and the type to choose for a given database, see Connect to your database. Copy the vendor's JDBC .jar file into the drivers folder of the BroadSQL installation (directly in it, not in a subfolder), then restart BroadSQL: the launchers load the drivers folder when BroadSQL starts. Then SHOW DRIVERS; confirms it: each driver of the drivers folder is listed with its version and its class, with the source drivers folder. A JAR file copied while BroadSQL was running is listed with Restart BroadSQL to load it; DETAILED adds the JAR path, the database types the driver serves and any message the driver wrote while it was inspected.

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.

Microsoft SQL Server and Windows authentication

The Microsoft SQL Server driver uses a native library only for Windows integrated authentication (integratedSecurity=true in the URL): mssql-jdbc_auth-<version>.x64.dll (sqljdbc_auth.dll in older drivers), shipped in the driver's download. With a user name and a password (SQL Server authentication), the library is not needed. For integrated authentication, copy the library of the same version as the driver into a folder of the PATH environment variable, where Java finds native libraries on Windows. SHOW DRIVERS never loads this library, so it no longer prints a warning about it; a connection that needs it and cannot find it reports the driver's error.

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:

• SET PASSWORD changes a database password only on H2 and HSQLDB. On every other database type it refuses before changing anything: change the password with the tools of that database, then update the password BroadSQL saved with EDIT CONNECTION or CONFIG.
• 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 (SQLite, PostgreSQL, SQL Server, Apache Derby, 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 (also typed 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.

Found something wrong or unclear on this page? Tell us, with the page address.