How to start spring-boot app without depending on Database?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Spring Boot applications often fail early because DataSource or JPA auto-configuration expects a database that is not available yet. If the application should be able to start without a database, the fix is usually to disable the database-related auto-configuration, make database beans conditional, or separate profiles so the app can boot in a lighter mode.
Disable Database Auto-Configuration
If the application does not need a database at all in a given runtime, the simplest answer is to exclude the database auto-configuration classes.
This tells Spring Boot not to create a DataSource or JPA stack automatically. It is the right choice for services that truly do not need a database in certain deployments.
You can do the same in configuration:
That is useful when you want the behavior controlled by properties instead of hardcoded in the application class.
Use Profiles for Database and No-Database Modes
Many applications need two modes:
- local or integration mode with a database
- lightweight mode without one
Profiles keep that split clear.
Run with the database profile only when needed:
Without that profile, the database bean never exists, so the app can start in a database-free mode.
Make Database Consumers Conditional
Even if you disable auto-configuration, application beans may still inject repositories or DataSource directly and fail during startup. Those beans need conditional creation or a no-op implementation.
Now the rest of the application depends on CustomerStore, not on a specific database implementation.
Watch Out for Hidden Database Dependencies
The common failure is thinking only auto-configuration matters. In reality, startup can still fail because of:
- repository beans
- Flyway or Liquibase migrations
- JPA entity manager setup
- health checks that require a database
If the app should start without a database, those systems must also be disabled or made conditional.
Example:
This is especially important in local development, partial test environments, or command-line utilities built on Spring Boot.
Common Pitfalls
- Excluding
DataSourceAutoConfigurationbut leaving repository or JPA beans active still causes startup failure. - Using one configuration for every environment forces the application to require infrastructure that some modes do not need.
- Forgetting migrations and health checks can make the app still depend on a database even after auto-configuration is excluded.
- Injecting
DataSourcedirectly throughout the codebase makes no-database mode much harder to support cleanly. - Treating “start without a database” as a property tweak only, instead of as an application design decision, leads to brittle startup behavior.
Summary
- Exclude database auto-configuration when the application truly should not require a database to boot.
- Use profiles to separate database-enabled and database-free runtime modes.
- Make database-consuming beans conditional or provide alternative implementations.
- Disable migrations and DB-specific health checks when running without a database.
- Design the application around abstractions so startup mode changes do not ripple through the entire codebase.
Related reading
- How to stop insertion of Duplicate documents in a mongodb collection
- How to stop mongo DB in one command
- How to stop mysqld
- How to store arrays in MySQL?
- How to start Spring Boot app in Spock Integration Test
- How to start up spring-boot application via command line?
- How to store AWS Cognito User Pool users in DB for instance DynamoDB?
- How to store Emoji Character in MySQL Database

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.