Introduction

Logging SQL in Spring Boot is usually a combination of two separate needs: seeing the SQL statements themselves and seeing the bound parameter values. The exact configuration depends on whether you want quick Hibernate logging for debugging or a more structured query-logging solution.

Start with Hibernate SQL Logging

For JPA and Hibernate-based applications, the simplest first step is property-based logging configuration.

In application.properties:

spring.jpa.show-sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.orm.jdbc.bind=TRACE

In application.yml:

1spring:
2  jpa:
3    show-sql: true
4
5logging:
6  level:
7    org.hibernate.SQL: DEBUG
8    org.hibernate.orm.jdbc.bind: TRACE

This shows generated SQL plus bound parameter values on newer Hibernate versions. The exact logger names can vary with Hibernate generation, so check which version your application is using if parameter values do not appear.

Understand What Each Setting Does

These settings are related but not identical:

• 'spring.jpa.show-sql=true tells Hibernate to print SQL'
• 'org.hibernate.SQL=DEBUG routes SQL through the logging system'
• bind-parameter loggers show actual values sent into placeholders

In practice, the logger-based approach is usually more useful than relying only on show-sql, because it integrates with your normal logging configuration and levels.

Use Better Query Logging for Deep Diagnostics

If you need clearer output, timing, or cross-library SQL interception, tools such as datasource proxies or JDBC interceptors can be more useful than raw Hibernate logs.

For example, a datasource proxy library can log:

• executed SQL
• parameters
• execution time
• slow query thresholds

That becomes helpful when you need performance investigation rather than simple visibility into generated statements.

Use the Right Tool for the Debugging Goal

A useful rule is:

• use Hibernate SQL logs when you want to see generated ORM queries quickly
• use bind-value logging when placeholders are not enough
• use datasource interception when you need timing, slow-query analysis, or visibility across several persistence styles

Choosing the lighter option first keeps logs readable and avoids turning every debugging session into a logging firehose.

If your application uses more than one persistence style, a datasource-level logger can be especially helpful because it sees SQL regardless of whether it came from JPA, JDBC template code, or another library.

Keep SQL Logging Out of the Default Production Profile

A practical pattern is to enable verbose SQL logs only in development or a dedicated troubleshooting profile. That keeps production logs smaller and reduces the chance of leaking sensitive values through parameter logs.

Profile-specific configuration files make this straightforward:

• 'application-dev.yml with verbose SQL logging'
• 'application-prod.yml with quieter defaults'

Common Pitfalls

The biggest mistake is enabling verbose SQL and parameter logging in production without thinking about volume and sensitivity. Logs can grow quickly and may contain personally identifiable or confidential data.

Another common issue is assuming show-sql will always display parameter values. It often does not. Statement logging and bind-value logging are separate concerns.

People also forget that ORM-generated SQL is only one part of the picture. If the application uses plain JDBC, jOOQ, or another data-access layer in addition to Hibernate, you may need a broader logging approach.

Finally, if the real problem is query performance, logging every statement may not be enough. You may need slow-query detection, database-side analysis, or execution-plan inspection as well.

Summary

• Use Hibernate logging properties for the quickest SQL visibility in Spring Boot.
• Treat SQL text logging and bind-value logging as separate settings.
• Prefer logger-based configuration over show-sql alone for real debugging.
• Be careful with production logging because SQL logs can be noisy and sensitive.
• Use datasource-level tools when you need timing, interception, or framework-independent query logging.