spring-boot-data-source-decorator wraps your DataSource instead of replacing it

The DataSource you get is not the one you declared

The problem is that the DataSource your application autowires is rarely the object you think it is. Spring Boot creates one, a pool sits in front of it, and then a driver or a proxy sits in front of that, and by the time you want to log the SQL or count the queries, there is no obvious place to hook in without rewriting the bean definition and losing the auto-configured pool settings. This project is a set of Spring Boot auto-configurations that decorate the DataSource instead of replacing it, and it integrates with three libraries. P6Spy adds the ability to intercept and log SQL queries, including interception of most Connection, Statement and ResultSet method invocations. Datasource Proxy adds the ability to intercept all queries and Connection, Statement and ResultSet method calls. FlexyPool adds connection pool metrics in JMX, Codahale and Dropwizard flavours, and flexible strategies for adjusting pool size on demand. The audience is a Spring Boot team that wants observability on the database side without hand-wiring it.

Why not just wrap the DataSource in a configuration class

The README answers the obvious objection directly, with a section titled why not wrap DataSource in a configuration. You can do that, the project says, but this library also provides three things a manual wrapper does not. The first is the ability to use the @ConfigurationProperties provided by Spring Boot, so spring.datasource.hikari.* and spring.datasource.dbcp2.* keep working, which is the part that usually breaks when you take over the DataSource bean yourself. The second is disabling the decorating by deployment property, decorator.datasource.enabled=true or false, so a profiling or logging build can be turned off in production without a code change. The third is that you can configure the proxies through spring properties in application.properties or application.yml, and still customise the proxies by defining beans in the Spring context, so the default configuration is a starting point rather than a ceiling. The auto-configuration applies to your datasources whether they are auto-configured or custom, which is the sentence that makes it usable in an application that has its own DataSource bean.

The decorating order, when you use more than one

Using all three decorators at once is supported, and the order is fixed and documented:

P6DataSource -> ProxyDataSource -> FlexyPoolDataSource -> DataSource

Read from the left, the outermost wrapper is P6Spy, then Datasource Proxy, then FlexyPool, and the real DataSource at the bottom. The practical consequence is about what sees what. A query issued by the application passes through the P6Spy layer first, then the proxy layer, then the pool, so the SQL that P6Spy logs is the SQL that Datasource Proxy also observes, and the pool sits closest to the database. If you expected the pool to be the outermost thing, because that is how a plain auto-configured DataSource looks, this ordering is the thing to check first, since it decides whether the pool metrics count the queries that the proxies have already seen. The order is not described as configurable in the README, so it is worth treating as a fixed property of the starters rather than a knob.

One starter per decorator, and how to add one

The distribution is a Gradle multi-module project with an autoconfigure module and three starters, p6spy-spring-boot-starter, datasource-proxy-spring-boot-starter and flexy-pool-spring-boot-starter, plus a samples directory with a sample for each. Adding P6Spy to a Spring Boot 4 application in Gradle is:

implementation("com.github.gavlyukovskiy:p6spy-spring-boot-starter:${version}")

and the Maven form is:

<dependency>
    <groupId>com.github.gavlyukovskiy</groupId>
    <artifactId>p6spy-spring-boot-starter</artifactId>
    <version>${version}</version>
</dependency>

Datasource Proxy and FlexyPool have the same shape with their own artifact names. The version matters and there is a compatibility table in the README. For Spring Boot 4.x you take the latest release of the starters, and for Spring Boot 3.x the pinned version is 1.12.1. The releases follow that split, with v2.0.0 and v2.0.1 published on 2025-11-21 and 2026-05-15, and v1.12.1 published the same day as 2.0.0, which is consistent with two lines maintained in parallel for two Spring Boot generations. The last push was on 2026-10-14 and the project is not archived, and the licence is Apache 2.0 with the LICENSE.txt in the root.

P6Spy logging and the JdbcEventListener hook

With the P6Spy starter in place, every SQL query lands in the log, in the format the library uses:

2017-06-07 21:42:08 INFO p6spy: #1496860928120 | took 0ms | statement | connection 0|SELECT NOW()

Beyond the built-in logging, P6Spy supports pluggable listeners, and this project registers every bean of type JdbcEventListener into P6Spy, which is how you hook into connection events yourself:

@Bean
public JdbcEventListener myListener() {
    return new JdbcEventListener() {
        @Override
        public void onAfterGetConnection(ConnectionInformation connectionInformation, SQLException e) {
            System.out.println("got connection");
        }

        @Override
        public void onAfterConnectionClose(ConnectionInformation connectionInformation, SQLException e) {
            System.out.println("connection closed");
        }
    };
}

The mechanism is a RuntimeListenerSupportFactory added to the P6Spy modulelist, and the README notes that overriding that property prevents the factory from being registered, which in turn means your listeners are not applied. The configuration knobs are also few and explicit, and the README is clear that the values shown are the defaults and do not need to be set:

# Register P6LogFactory to log JDBC events
decorator.datasource.p6spy.enable-logging=true
# Use com.p6spy.engine.spy.appender.MultiLineFormat instead of com.p6spy.engine.spy.appender.SingleLineFormat
decorator.datasource.p6spy.multiline=true
# Use logging for default listeners [slf4j, sysout, file, custom]
decorator.datasource.p6spy.logging=slf4j
# Log file to use (only with logging=file)
decorator.datasource.p6spy.log-file=spy.log

FlexyPool needs to be told about your pool

One caveat in the README is worth reading before you choose FlexyPool. To use FlexyPool with a connection pool other than HikariCP you must add a PoolAdapter for your particular connection pool, and the link goes to the FlexyPool installation guide for the connection pool settings. That is a real difference between this starter and the other two. P6Spy and Datasource Proxy wrap at the DataSource level and work with whatever pool is underneath, because they intercept the JDBC calls. FlexyPool does not only wrap the DataSource, it manages the pool, so it has to understand the pool's own API, and that is what the adapter is for. HikariCP needs no such adapter, so in the common case nothing is needed, but a project on Commons DBCP2, or on a managed data source, will have to supply the adapter before the pool metrics appear. The metrics themselves come in JMX, Codahale and Dropwizard flavours, and the flexible strategies are the part that lets you resize the pool on demand rather than at configuration time.

Where a decorator is the wrong answer

Three cases. The first is a performance investigation in production, where logging every statement is the wrong shape of tool, because the log volume changes the behaviour you are measuring and the queries you want to see are rarely the ones that dominate the log. The decorator.datasource.enabled property exists for exactly this, and a deployment profile that turns it on for a short window is a better plan than a permanent logger. The second is a codebase that already wraps its DataSource for another reason, such as a tenant routing or a read replica switch, because then you have two layers of wrapping and the order between them is your problem, and the documented order in this project only covers the three decorators it ships. The third is a service that already has query observability through a different route, in which case the marginal value of a JDBC-level logger is low compared with the cost of another moving part. The honest summary is that this project removes a small amount of wiring from a common Spring Boot task, and the two things to weigh are the version line you are on and whether your pool needs an adapter.

Editorial conclusion

spring-boot-data-source-decorator is the right choice when you need to see the SQL your application really sends, or you need pool metrics, and you would rather not add a hand-written @Bean that wraps the DataSource, because the starter keeps your existing spring.datasource.hikari.* and spring.datasource.dbcp2.* configuration working and can be turned off in a deployment profile. It is the wrong tool if your application already wraps its DataSource for a reason, since the decorator order then becomes your problem rather than the library's. Before adopting it, check the Spring Boot line you are on, since 4.x uses the 2.x starters and 3.x is pinned to 1.12.1, remember that FlexyPool needs an explicit PoolAdapter for any pool other than HikariCP, and keep the P6Spy logging off in production unless you intend to pay for the log volume.

Frequently asked questions

Official sources

1. gavlyukovskiy/spring-boot-data-source-decorator on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases