5 minute read

Open J Proxy (OJP) – Origins

Robetti Rogerio

11. August 2025

By Rogerio Robetti

“How a nagging question, some downtime, and a touch of guilt led to an open-source project to make JDBC smarter.”

🚦 Chapter 1: The Seed of a Problem

The idea behind Open J Proxy (OJP) started growing in my mind way back in 2018 or 2019, during my time at a large credit card provider corporation. We were gearing up for a big shift: transitioning systems into microservices. Exciting stuff—but as we all know, excitement often walks hand-in-hand with complexity.

In one of our early design discussions, I remember asking:

“If each microservice has its own connection pool, and we scale elastically… what happens when we hit the database with all those connections at once?”

The silence in the room was telling.

Eventually, someone said something like, “Well, we’ll just scale the Oracle RAC cluster”. And yeah, that works. But does it really solve the problem? Not for me. The Java world didn’t seem to have a native, elegant answer for how to control and coordinate JDBC connections under elastic scaling. And that bugged me.

But as with most corporate projects, other priorities took over. And like a background thread with very low priority, the idea quietly slipped into the backlog of my brain.

🧠 Chapter 2: High-Scale Research, and Déjà Vu

Fast-forward to 2019–2021, when I was doing advanced research at a Leading telecom equipment firm. My team worked on monitoring and query tracking for large-scale distributed systems. We weren’t solving the same problem, but once again, query-level visibility and DB pressure surfaced as recurring concerns. It reignited the memory of that unsolved challenge back at the large credit card corporation.

Still, life was busy. Projects moved on. The idea lingered in the back of my mind— again became a quiet background process with low CPU priority.

💡 Chapter 3: A Window of Time (and a Bit of Guilt)

At the end of 2024, a contract I was on wrapped up. Suddenly, I had that rarest of things in tech: free time. I started reviewing old notes and ideas, and there it was—the same nagging question staring me in the face again.

This time, though, I had more experience—and more tools. Influences from good friends like Roger Floriano (from Switcher API) also pushed me forward. And honestly? I felt a bit guilty. I’d used open-source tools for years without giving much back.

It was time.

🧪 Chapter 4: The “What If?”

One morning, a single question lit everything up:

“What if I could run HikariCP inside a gRPC server, expose a lightweight Protocol Buffers API, and still talk JDBC?”

That question unlocked the architecture of what would become OJP:

A server manages a central, well-tuned connection pool (HikariCP).
Applications connect via JDBC, with no code changes.
Communication uses blazing-fast HTTP/2 gRPC.
It adds a telemetry layer, circuit breakers, and load protection.

OJP High-Level Design

🔧 What’s Inside OJP?

✅ gRPC-based Proxy Server
✅ Standard JDBC Client Jar – plug-and-play
✅ Connection Pooling via HikariCP
✅ Circuit Breaker (fails fast, resets)
✅ OpenTelemetry/Prometheus ready Telemetry
✅ Spring Boot / Quarkus / Micronaut tested compatibility
✅ Support for MySQL, PostgreSQL, Oracle, SQL Server, DB2, MariaDB and in theory any other database that has a JDBC implementation.

It’s lightweight, resilient, and designed to fit modern cloud-native Java apps.

The goal?

Build something drop-in for Java apps, backed by HikariCP (arguably the most trusted connection pool in the Java world), gRPC for low-latency communication, and full JDBC spec compatibility, so that legacy apps also benefit.

⚙️ Chapter 5: From POC to MVP

The first proof of concept was exciting but rough. I shared the idea without some colleagues that are very experienced in Java, they immediately saw the value — and offered brilliant suggestions to expand and harden it.

I refined the POC into an MVP and began stress testing it.

At first? Nothing special.

Then came the epiphany: One test query was always failing. That query dragged performance, CPU usage spiked in the database. Does the scenario rings a bell?

What if we included a circuit breaker on the server?

Boom!

Query failures were intercepted before reaching the DB. Combined with fine-tuned configs, performance metrics shot up:

📉 Lower average query times
💡 Reduced CPU usage
🚀 Better throughput under load

And even thought the performance results are preliminary, they are certainly encouraging.

Thanks to contributions from Roger Floriano, we also added powerful telemetry pipelines and monitoring capabilities that made OJP even more production-ready.

Getting Started with OJP: 4 Simple Steps

You’ve heard the why—now here’s the how. Getting Open J Proxy up and running is fast, frictionless, and requires no code changes in your application. Whether you’re working locally or in the cloud, OJP is designed to integrate seamlessly into your Java stack.

Follow these four steps to get started:

1. Start OJP Server

Spin up the OJP server as a Docker container. It boots fast and runs a gRPC-based proxy with HikariCP under the hood:

docker run --rm -d -p 1059:1059 rrobetti/ojp:0.0.7-alpha

This exposes OJP on port 1059 by default. You can change the port as needed.

2. Add OJP JDBC Driver to your project

Next, bring in the OJP client driver—just a standard Maven dependency that speaks JDBC but routes through the proxy:

<dependency>
    <groupId>org.openjdbcproxy</groupId>
    <artifactId>ojp-jdbc-driver</artifactId>
    <version>0.0.7-alpha</version>
</dependency>

It’s lightweight, self-contained, and compatible tested with Spring Boot, Quarkus, Micronaut, and in principle should work with any other java framework that relies on JDBC.

3. Update your JDBC URL

// Before  
spring.datasource.url=jdbc:postgresql://user@localhost/mydb

// After  
spring.datasource.url=jdbc:ojp[localhost:1059]_postgresql://user@localhost/mydb
//localhost:1059 assumes OJP server running in the same machine, if not change to the correct host name or IP.

// And set the OJP JDBC driver
spring.datasource.driver-class-name=org.openjdbcproxy.jdbc.Driver

> 📍Note: Replace localhost:1059 with your OJP server’s address if running remotely.

This lets your application keep using standard JDBC while OJP handles pooling, telemetry, and fault tolerance behind the scenes.

4. Remove the Default Connection Pool (Spring Boot)

Since OJP handles connection pooling at the proxy level, you’ll want to exclude HikariCP (or any other local pooler) from your app’s classpath:

   <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jdbc</artifactId>
        <exclusions>
            <!--When using OJP proxied connection pool the local pool needs to be removed -->
            <exclusion>
                <groupId>com.zaxxer</groupId>
                <artifactId>HikariCP</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

> ⚠️ Pro tip: You’ll start seeing OJP’s benefits most clearly under pressure—heavy traffic, scaling events, or erratic queries.

🚀 What’s Next

We’re preparing a public BETA release, and looking for Java developers, platform engineers, and DBA teams to try it in real workloads, report feedback, and help shape its roadmap.

If you’re interested in performance, observability, and simplifying your database connection architecture — OJP is for you.

🙌 Acknowledgments

This journey wouldn’t be possible without some amazing people.

💡 Roger Floriano – for his critical contributions to OJP’s telemetry layer and architectural improvements.

🧠 Diego Vagliati – for his enthusiastic engagement and a series of brilliant technical suggestions, many of which are now on the roadmap to be prototyped.

📣 Carolina Cobo – for her early and insightful feedback on communication strategy, developer engagement, and identifying the right venues to showcase OJP’s value.

To all who contributed—technically or strategically—thank you for believing in the vision.