Revision history [back]

That is correct. We don't bundle JDBC drivers with the product, for a number of reasons.

1. The drivers themselves change and have bugfixes released frequently. We don't want to synchronize our release schedule to them.
2. There are a large number of databases out there. It would be very difficult to stay on top of all of them for bundling purposes, not to mention increasing the size of the package significantly.
3. Even for the same RDBMS server, there are often different drivers available for different use cases and feature requirements. In that case, we wouldn't be able to automatically select a single driver for a given JDBC URI prefix.

The only exception to this is the RDBMS specific origins (ex: MS SQL CDC, Oracle CDC, etc.). In that case, the stage in question includes any jars it depends on and you don't need to install them yourself.

That is correct. We don't bundle JDBC drivers with the product, for a number of reasons.

1. The drivers themselves change and have bugfixes released frequently. We don't want to synchronize our release schedule to them.
2. There are a large number of databases out there. It would be very difficult to stay on top of all of them for bundling purposes, not to mention increasing the size of the package significantly.
3. Even for the same RDBMS server, there are often different drivers available for different use cases and feature requirements. In that case, we wouldn't be able to automatically select a single driver for a given JDBC URI prefix.
4. There are often licensing issues involved with packaging 3rd party code, particularly JDBC drivers. We often aren't legally allowed to do this.

The only exception to this is the RDBMS specific origins (ex: MS SQL CDC, Oracle CDC, etc.). In that case, the stage in question includes any jars it depends on and you don't need to install them yourself.