spring-boot
application-development
database-independence
java
tutorial

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.

Practice system design

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.

java
1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;
4import org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration;
5
6@SpringBootApplication(
7    exclude = {
8        DataSourceAutoConfiguration.class,
9        HibernateJpaAutoConfiguration.class
10    }
11)
12public class DemoApplication {
13    public static void main(String[] args) {
14        SpringApplication.run(DemoApplication.class, args);
15    }
16}

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:

properties
spring.autoconfigure.exclude=\
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

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.

java
1import javax.sql.DataSource;
2import org.springframework.context.annotation.Bean;
3import org.springframework.context.annotation.Configuration;
4import org.springframework.context.annotation.Profile;
5import org.springframework.jdbc.datasource.DriverManagerDataSource;
6
7@Configuration
8@Profile("db")
9public class DatabaseConfig {
10    @Bean
11    public DataSource dataSource() {
12        DriverManagerDataSource ds = new DriverManagerDataSource();
13        ds.setDriverClassName("org.h2.Driver");
14        ds.setUrl("jdbc:h2:mem:testdb");
15        ds.setUsername("sa");
16        ds.setPassword("");
17        return ds;
18    }
19}

Run with the database profile only when needed:

bash
java -jar app.jar --spring.profiles.active=db

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.

java
public interface CustomerStore {
    String findName(long id);
}
java
1import org.springframework.context.annotation.Profile;
2import org.springframework.stereotype.Service;
3
4@Service
5@Profile("db")
6public class JdbcCustomerStore implements CustomerStore {
7    @Override
8    public String findName(long id) {
9        return "from-db-" + id;
10    }
11}
java
1import org.springframework.context.annotation.Profile;
2import org.springframework.stereotype.Service;
3
4@Service
5@Profile("!db")
6public class InMemoryCustomerStore implements CustomerStore {
7    @Override
8    public String findName(long id) {
9        return "placeholder-" + id;
10    }
11}

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:

properties
spring.flyway.enabled=false
spring.liquibase.enabled=false
management.health.db.enabled=false

This is especially important in local development, partial test environments, or command-line utilities built on Spring Boot.

Common Pitfalls

  • Excluding DataSourceAutoConfiguration but 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 DataSource directly 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
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track 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.

Practice system design

All Rights Reserved.