In many modern enterprise architectures, developers face the same hurdle: direct TCP/IP connections to the database (via classic ports like 1521, 3306, or 5432) are often strictly regulated for security reasons, blocked by firewalls, or simply undesirable in cloud environments.

To connect Java applications to their data sources nonetheless, teams frequently rely on middleware or specialized protocols. However, existing open-source alternatives often came with compromises - whether through limitations in standards, abandoned projects, or complex integration hurdles. With remoteJDBC, a modern open-source solution is now available that enables JDBC communication seamlessly and straightforwardly over HTTP(s).

Existing Alternatives at a Glance

Those who previously needed to connect databases via HTTP or remote setups typically encountered a few well-known options, each with its own limitations:

• OJP (Open-J-Proxy): A fully open-source project that works very well, but standardly requires its own server process and an additional port. While an extension exists to enable HTTP(s), it is not tightly integrated into the core project, and incorporating it into custom applications often requires numerous additional dependencies, which can easily lead to version conflicts.
• Apache Calcite / Avatica: A powerful framework, but in the realm of JDBC, it often covers only a subset of the standard and thus does not universally address all requirements.
• AceQL: Offers a working HTTP-based JDBC connection, but the server-side component is tied to a commercial license (not for all database systems) and number of "database names". This restricts its use in pure open-source or cost-free projects.
• VJDBC: A historically well-known approach for remote JDBC, but it has not been actively developed for many years and lacks modern Java standards and security features.

The remoteJDBC project sets out to solve precisely these friction points.

What is remoteJDBC?

remoteJDBC is an open-source driver by SIB Visions designed to bridge the gap in HTTP-based database communication. The project's goal is to provide a broad and practical implementation of the JDBC standard over HTTP(s) - consistently under the GPLv3 to safeguard the true open-source ethos.

The approach allows you to retain your familiar JDBC code in Java applications, while SQL queries and results are securely transmitted in the background using a standardized HTTP protocol.

The Highlights: Feature Set in Detail

In daily use, the driver scores points with thoughtful technical characteristics that go far beyond a simple forwarding proxy:

• HTTP(s)-Native Communication: Directly utilizes standard web infrastructure. Firewalls, proxies, and load balancers that allow web traffic are passed through without issue - requiring no special VPN tunnels or the opening of sensitive database ports.
• Prepared Statements & Parameters: Supports not only simple SQL queries but also parameterized
  PreparedStatements for secure and performant execution.
• Transaction Management: Enables the familiar control of transactions (including commit and rollback) to ensure data consistency across the HTTP boundary.
• Metadata Processing: Provides support for DatabaseMetaData and ResultSetMetaData, which is especially vital for ORM frameworks or generic dataset applications.
• Lean Dependencies: Unlike complex proxy solutions, remoteJDBC is structured to integrate cleanly into existing projects without unnecessary overhead or the risk of version conflicts.
• Consistent Open Source (GPLv3): Full transparency and freedom in the source code, ideal for projects that actively support and live the open-source philosophy.

Who is remoteJDBC for?

The driver is particularly interesting for:

• Cloud and Container Architectures, where direct database connections across network boundaries should be avoided.
• Applications in Restricted Networks, where exclusively standard web ports (80/443) are open.
• Projects with Minimal Dependencies, seeking a clean and straightforward integration without excessive ballast.
• Scenarios Involving Communication Between Virtual Machines (VMs) that need to communicate via JDBC over standardized protocols.
• Developers and Architects looking for a performant, open-source alternative to proprietary middleware solutions.

Outlook and Contributing

Since the project is hosted as open source on GitHub, it thrives on community feedback and contributions. If you are looking for a flexible way to address databases over HTTP and want a clean alternative to commercial tools or complex proxy setups, it is well worth a look:

remoteJDBC @ GitHub

Try out the driver, test it in your scenarios, and feel free to leave feedback or issues on GitHub to actively support us!