Service Provider Interface (SPI)

R2DBC defines an SPI all data store drivers must implement.

  • r2dbc-spi: a set of interfaces defining the SPI for R2DBC.
  • r2dbc-spi-test: within the SPI repository, a Technology Compatibility Kit (TCK) for verifying a driver’s implementation.

One noticeable difference between R2DBC and JDBC is that JDBC is aimed at both driver writers and application developers. Driver developers and application developers operate at different levels, making this one-size-fits-all model less than ideal.

R2DBC’s SPI is deliberately designed to be as small as possible, while still including features critical for any relational data store. This means that the SPI does not target extensions which are specific to a data store.

To ease implementation, R2DBC also provides a test interface (a veritable TCK) to ensure your driver is fully operational.

Driver Implementations

R2DBC drivers implement the SPI listed above. The ones currently supported include:

Connection Pooling

The following connection pool implementations are available for R2DBC:

  • r2dbc-pool - reactive connection pooling using Reactor Pool.


Observability is provided through r2dbc-proxy.

Implementing a Driver

R2DBC has a clearly-defined SPI, which you must implement to host a solution for your data store. To build an implementation, add the following artifact to your build:

  • Group io.r2dbc
  • Artifact r2dbc-spi

The key interface that all driver providers must implement is the Connection, along with a set of other interfaces. Check out the specification for details on R2DBC Driver Compliance.

There are other parts to implement, but this is the core.

Technology Compatibility Kit (TCK)

R2DBC also has a suite of test cases to verify your driver’s support. Your data store implementation should import a test-scoped dependency on the following artifact:

  • Group io.r2dbc
  • Artifact r2dbc-spi-test

To run all of the expected tests, write an implementation of the TCK’s TestKit test.