Skip to content

Integrating eXate Service into a JDBC Driver

Purpose

This guide outlines the typical effort required to integrate the eXate JDBC Core with a new JDBC driver, enabling eXate's transparent data protection capabilities for an additional database platform.

The eXate JDBC Core is a database-agnostic middleware layer that wraps standard JDBC interfaces and intercepts SQL execution and ResultSet retrieval. Protection operations such as encryption, reconstruction, and manifest lookups are performed through eXate services via gRPC, allowing applications to interact with protected databases without any code changes.

Integration Scope

To enable a new JDBC driver to work with eXate, the driver implementation typically includes:

  • Adding the eXate JDBC Core dependency
  • Implementing the required database-specific Service Provider Interfaces (SPIs)
  • Creating a thin connection wrapper
  • Registering vendor-specific handlers
  • Testing query parsing, SQL rewrite behaviour, ResultSet reconstruction, and stored procedure support against the database dialect

The primary vendor-specific components implemented in the driver are:

MetadataHandler: responsible for database metadata access and dialect-specific behaviour, including retrieving stored procedure definitions, identifying system or administrative queries that should bypass protection, and handling binary or vendor-specific data types.

SqlSanitizer: an optional hook used to normalize vendor-specific SQL syntax before parsing. This may be required for databases that include optimizer hints, special comments, or non-standard SQL constructs.

Effort from the Driver Team

While the amount of new code required is typically modest, delivering a stable production driver requires validation across real SQL workloads and database behaviours.

Phase Typical Effort
Driver scaffolding and core integration 3 to 5 days
SPI implementation for metadata and SQL handling 5 to 8 days
Dialect-specific fixes and stored procedure support 3 to 5 days
Testing, QA, and hardening 5 to 10 days

Typical driver team effort: approximately 3 to 4 weeks.

Additional Effort from the eXate Team

In parallel with driver development, the eXate engineering team may perform limited database-specific tuning within the eXate Core services to optimise behaviour for the target database, including:

  • Tuning SQL parsing behaviour for dialect-specific syntax
  • Validating query rewrite compatibility
  • Adjusting protection service behaviour for database-specific data types
  • Validating performance characteristics with the target database
  • Assisting with troubleshooting during integration testing

These activities are typically incremental enhancements rather than new platform work.

What's Already Built

The majority of the eXate platform capabilities required to support new drivers have already been implemented within the eXate JDBC Core, including:

  • Database-agnostic SQL parsing
  • Manifest-driven protection logic
  • Automated WHERE clause encryption
  • Transparent ResultSet reconstruction
  • Stored procedure decomposition and protection
  • gRPC orchestration with the eXate Protection Service

This architecture significantly reduces the effort required to onboard additional database drivers.

Summary

Integrating eXate support into a JDBC driver is a contained engineering effort, primarily focused on implementing a small number of database-specific interfaces and validating behaviour against the target database dialect.

Because the protection engine, SQL analysis, and service orchestration are already implemented within the eXate JDBC Core, most new driver integrations can be delivered in approximately one month of engineering effort, with limited additional tuning required from the eXate platform team.