Introduction

Spring Boot makes validation easy by auto-configuring Bean Validation and integrating it with request binding and JPA lifecycle hooks. That default is useful most of the time, but there are cases where you need to disable validation for performance, migration, or compatibility reasons. This guide explains what to disable, where to disable it, and how to avoid breaking behavior unexpectedly.

Core Topic Sections

Understand which validation layer you are disabling

In many projects, people say “Hibernate validation” but there are multiple paths involved:

1. Request and DTO validation via Bean Validation annotations such as @NotNull.
2. JPA entity lifecycle validation before persist or update.
3. Method validation with @Validated on services.

Disabling one layer does not always disable all others. Decide scope first so you do not disable more than intended.

Disable JPA entity lifecycle validation only

If your problem is entity validation during persistence, disable JPA validation mode while keeping request validation alive.

Add this to application.yml:

1spring:
2  jpa:
3    properties:
4      jakarta.persistence.validation.mode: none

For older stacks using javax, use javax.persistence.validation.mode instead.

This is the safest option when you still want validation at API boundaries but not at entity flush time.

Disable Spring Boot validation auto-configuration

If you want to disable validation framework wiring across the app, exclude validation auto configuration at startup.

1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3import org.springframework.boot.autoconfigure.validation.ValidationAutoConfiguration;
4
5@SpringBootApplication(exclude = ValidationAutoConfiguration.class)
6public class DemoApplication {
7    public static void main(String[] args) {
8        SpringApplication.run(DemoApplication.class, args);
9    }
10}

This can affect request binding and custom validator beans. Use this only when you intentionally want broad disablement.

Remove validation starter dependency when appropriate

If your project includes spring-boot-starter-validation, removing it avoids auto-registration of validator infrastructure.

Maven example:

1<dependency>
2  <groupId>org.springframework.boot</groupId>
3  <artifactId>spring-boot-starter-web</artifactId>
4  <exclusions>
5    <exclusion>
6      <groupId>org.springframework.boot</groupId>
7      <artifactId>spring-boot-starter-validation</artifactId>
8    </exclusion>
9  </exclusions>
10</dependency>

This method is clear at build level, but verify no module depends on validation annotations at runtime.

Disable method validation behavior selectively

If service-level @Validated checks are causing issues, remove @Validated from those beans or move validation to specific entry points.

Example before:

1import jakarta.validation.constraints.NotBlank;
2import org.springframework.validation.annotation.Validated;
3
4@Validated
5public class UserService {
6    public void createUser(@NotBlank String username) {
7        // business logic
8    }
9}

Example after selective disable:

1public class UserService {
2    public void createUser(String username) {
3        // manual checks or upstream validation
4    }
5}

Do this only with a replacement rule set, otherwise invalid data can leak into core workflows.

Keep boundary validation if possible

A practical compromise in many systems:

1. Keep validation on public API request DTOs.
2. Disable JPA lifecycle validation to reduce persistence overhead.
3. Keep domain-specific checks in service layer where context exists.

This model preserves safety while removing redundant checks on hot write paths.

Verification checklist after disabling

After changing validation behavior, test these flows explicitly:

1. Invalid API payload handling.
2. Persistence of malformed entities.
3. Method calls previously protected by @Validated.
4. Integration with generated clients and external callers.

Also review logs for reduced ConstraintViolationException volume and confirm this is expected, not hidden failure.

Migration and rollout strategy

If disabling validation as part of migration, treat it as temporary and controlled:

1. Document exact reason and scope.
2. Add issue tracker link in config comments.
3. Re-enable in stages with focused regression tests.

Without rollback plan, temporary changes often become permanent technical debt.

Common Pitfalls

• Disabling global validation when only JPA lifecycle validation needed to be turned off.
• Forgetting that @Validated method checks can still run even after JPA setting changes.
• Removing validation starter without checking transitive module expectations.
• Turning off validation without adding replacement checks at trusted boundaries.
• Shipping config changes without regression tests for invalid input handling.

Summary

• “Hibernate validation” can mean multiple layers and should be scoped precisely.
• Use JPA validation mode settings for targeted persistence-layer disablement.
• Excluding auto configuration or dependency is broader and riskier.
• Keep validation at external boundaries whenever possible.
• Treat validation disablement as an explicit, tested architecture decision.