Bringing Your Own JDBC Driver

embedded: true needs nothing extra - H2’s driver already ships with the tool. Pointing jdbcUrl at anything else (Oracle, SQL Server, PostgreSQL, MySQL, or any other database) needs that database’s own JDBC driver, which isn’t something this tool can bundle in advance for every database anyone might use.

In the GUI, File > Import JDBC Driver…​ picks the jar(s) for you and copies them to the right place - select more than one file at once if the driver ships as a main jar plus separate dependency jars (Oracle’s ojdbc plus orai18n, for example).

Without the GUI, drop the driver’s .jar file into:

(Override the location with the ngoe.jdbc.drivers.dir system property if you need the drivers somewhere else - the GUI option above honors this too.)

That’s it - no restart, no other configuration. The next time a jdbc writer or extractor connects to a non-embedded jdbcUrl, it scans this directory and registers any driver it finds. Already-registered jars aren’t rescanned, so adding a second driver later doesn’t re-touch the first - but it also means replacing an existing driver jar with an updated version in place, rather than adding a new one, only takes effect after restarting (the GUI’s Import option warns about this if it looks like that’s what you’re doing). This works with any standard JDBC 4+ driver jar - which is to say, essentially any driver you’d download today; almost every vendor (Oracle’s ojdbc, MySQL’s Connector/J, PostgreSQL, Microsoft’s mssql-jdbc, and so on) ships one that self-registers this way, so there’s nothing driver-specific to configure beyond having the right jdbcUrl for that database.

If a driver doesn’t seem to be picked up, check the application log for a Could not load JDBC driver jar warning - this usually means the jar isn’t a genuine driver jar (or is corrupt), rather than a configuration problem on your end.