Why Store All Spring Boot Configurations in a Database? Benefits and Implementation Guide

Why Store All Spring Boot Configurations in a Database?

Traditional YAML configuration files are concise but cause many pain points in production: changes require application restarts, multi‑environment management becomes complex, and version control is difficult.

This article introduces a new solution—storing all application configurations, including database settings, in a database to achieve fully dynamic configuration management.

Problems with Static YAML

1. High change cost Each configuration change triggers a full release cycle: modify → rebuild → deploy → restart, which is cumbersome for fast‑moving production environments.

Imagine needing to adjust the database connection pool size and having to redeploy the entire service.

2. Multi‑environment complexity When a project has development, testing, staging, and production environments, configuration management becomes unusually complex, requiring multiple nearly identical files and manual synchronization.

3. Security risks Sensitive information such as database passwords and API keys are stored in plain text, posing obvious audit risks.

4. Collaboration bottleneck Configuration changes often need developer involvement, preventing operations teams from independently tuning settings.

Why Not Use a Configuration Center?

Popular products like Nacos, Apollo, and Spring Cloud Config provide dynamic configuration, multi‑environment support, and gray releases, but they also have limitations:

1. Additional infrastructure complexity A configuration center itself requires deployment, monitoring, backup, and upgrades, adding operational burden for small teams.

2. Learning curve and technical debt Each center has its own API, SDK, UI, and best practices; migrating away later can be costly.

3. Network dependency and availability risk If the center is unavailable, application startup fails; local caching introduces consistency challenges.

4. Feature overload and customization difficulty Centers bundle many features that may be unnecessary for a specific project, increasing complexity.

5. Data isolation and fine‑grained security Shared configuration stores may not meet strict enterprise isolation requirements.

Advantages of Full Database Configuration

Zero extra infrastructure : The database is already a required component, so no new services are introduced.

Complete control : Storage, access, and security policies are fully owned and can be deeply customized.

Business integration friendliness : Configuration and business data coexist, simplifying complex business logic.

Simplified architecture : Fewer external dependencies reduce overall system complexity.

This approach suits projects that need specific configuration management, want to reduce external dependencies, and prefer a lightweight solution.

Architecture Design and Core Implementation

The core challenge is the cold‑start problem: how does an application connect to the configuration database when all settings are stored there?

We adopt a layered bootstrapping strategy:

1. Boot‑layer configuration : Minimal hard‑coded settings that contain only the connection info for the configuration database.

2. Core configuration layer : Application‑wide settings stored in the configuration database (data source, cache, etc.).

3. Business configuration layer : Business‑specific parameters stored in the business database.

Unified Configuration Entity Design

@Data
@NoArgsConstructor
@AllArgsConstructor
public class ApplicationConfig {
    private Long id;
    private String configKey;
    private String configValue;
    private String configType; // datasource, redis, kafka, business, framework
    private String environment;
    private String description;
    private Boolean encrypted = false;
    private Boolean requiredRestart = false; // 是否需要重启应用
    private Boolean active = true;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
    private String createdBy;
    private String updatedBy;
}

The configType field distinguishes different configuration categories.

Configuration Loading and Core Implementation

@Slf4j
public class EarlyDatabaseConfigInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        ConfigurableEnvironment environment = applicationContext.getEnvironment();
        try {
            log.info("开始早期数据库配置加载...");
            Map<String, Object> dynamicProperties = loadDynamicProperties(environment);
            if (!dynamicProperties.isEmpty()) {
                MapPropertySource dynamicPropertySource = new MapPropertySource("earlyDatabaseConfiguration", dynamicProperties);
                MutablePropertySources propertySources = environment.getPropertySources();
                propertySources.addFirst(dynamicPropertySource);
                log.info("成功从数据库加载 {} 个早期配置项", dynamicProperties.size());
                dynamicProperties.forEach((key, value) -> {
                    if (key.contains("port") || key.contains("server") || key.contains("datasource")) {
                        log.info("早期加载配置: {} = {}", key, isPasswordField(key) ? "******" : value);
                    }
                });
            } else {
                log.warn("数据库中没有找到早期配置数据");
            }
        } catch (Exception e) {
            log.error("早期数据库配置加载失败，将使用默认配置", e);
        }
    }
    // ... (methods loadDynamicProperties, extractLoggerName, applyLoggingConfigurations, buildPropertyKey, isPasswordField)
}

Dynamic Configuration Service

@Service
@Slf4j
public class DynamicConfigurationService {
    @Autowired private ApplicationConfigRepository configRepository;
    @Autowired private ConfigHistoryRepository historyRepository;
    @Autowired private ConfigurableApplicationContext applicationContext;
    @Autowired private ConfigEncryptionService encryptionService;
    @Autowired private EnvironmentUtil environmentUtil;
    // Methods for updating datasource, Redis, business, framework configs, environment property updates, validation, saving to DB, creating DataSource, replacing beans, etc.
}

Configuration Management REST API

@RestController
@RequestMapping("/api/config")
@Slf4j
public class UniversalConfigController {
    @Autowired private DynamicConfigurationService configService;
    @Autowired private ApplicationConfigRepository configRepository;
    @GetMapping("/{configType}/{environment}")
    public ResponseEntity<Map<String, String>> getConfig(@PathVariable String configType, @PathVariable String environment) {
        List<ApplicationConfig> configs = configRepository.findByConfigTypeAndEnvironment(configType, environment);
        Map<String, String> configMap = configs.stream()
            .collect(Collectors.toMap(ApplicationConfig::getConfigKey, ApplicationConfig::getConfigValue));
        return ResponseEntity.ok(configMap);
    }
    // POST endpoints for datasource, Redis, business, and history retrieval omitted for brevity
}

Special Handling for Database‑Self Configuration

Because all configurations reside in the database, we face a "chicken‑or‑egg" problem. The solution is to keep a minimal boot‑layer configuration that only contains the connection details for the configuration database, optionally supplied via environment variables.

# bootstrap.yml - only boot configuration
spring:
  application:
    name: dynamic-config-app
  config-datasource:
    url: jdbc:mysql://config-db:3306/app_config
    username: ${CONFIG_DB_USER:config_user}
    password: ${CONFIG_DB_PASS:config_password}
    driver-class-name: com.mysql.cj.jdbc.Driver

Advanced Features

Configuration Encryption and Security

@Component
public class ConfigEncryptionService {
    private final AESUtil aesUtil;
    public ConfigEncryptionService() {
        this.aesUtil = new AESUtil(getEncryptionKey());
    }
    public String encryptSensitiveConfig(String plainText) { return aesUtil.encrypt(plainText); }
    public String decryptSensitiveConfig(String encryptedText) { return aesUtil.decrypt(encryptedText); }
    public boolean isSensitiveConfig(String configKey) {
        return configKey.toLowerCase().contains("password") ||
               configKey.toLowerCase().contains("secret") ||
               configKey.toLowerCase().contains("key") ||
               configKey.toLowerCase().contains("token");
    }
}

Configuration Version Control

@Entity
@Table(name = "config_history")
public class ConfigHistory {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String configKey;
    private String configType;
    private String oldValue;
    private String newValue;
    private String environment;
    private String operatorId;
    private String changeReason;
    @CreationTimestamp
    private LocalDateTime changeTime;
    // getters/setters omitted
}

@Service
public class ConfigVersionService {
    @EventListener
    public void recordConfigChange(ConfigurationChangeEvent event) {
        ConfigHistory history = new ConfigHistory();
        history.setConfigKey(event.getConfigKey());
        history.setConfigType(event.getConfigType());
        history.setOldValue(event.getOldValue());
        history.setNewValue(event.getNewValue());
        history.setEnvironment(event.getEnvironment());
        history.setOperatorId(getCurrentUserId());
        history.setChangeReason(event.getChangeReason());
        historyRepository.save(history);
    }
    public void rollbackConfig(String configKey, String environment, Long historyId) {
        ConfigHistory history = historyRepository.findById(historyId)
            .orElseThrow(() -> new RuntimeException("历史记录不存在"));
        configService.updateConfig(configKey, environment, history.getOldValue());
        log.info("配置已回滚 - Key: {}, 环境: {}, 回滚到版本: {}", configKey, environment, historyId);
    }
}

Configuration Monitoring and Alerting

@Component
public class ConfigurationMonitorService {
    @EventListener @Async
    public void handleConfigChange(ConfigurationChangeEvent event) {
        recordConfigChangeMetrics(event);
        sendChangeNotification(event);
        checkConfigCompliance(event);
    }
    private void recordConfigChangeMetrics(ConfigurationChangeEvent event) {
        Metrics.counter("config.changes.total",
            "type", event.getConfigType(),
            "environment", event.getEnvironment()).increment();
    }
    private void sendChangeNotification(ConfigurationChangeEvent event) {
        if (isCriticalConfig(event.getConfigKey())) {
            notificationService.sendCriticalConfigChangeAlert(event);
        }
    }
    @Scheduled(fixedRate = 300000)
    public void healthCheck() {
        checkConfigDatabaseHealth();
        checkConfigCacheHealth();
        checkConfigSyncStatus();
    }
}

Initialization and Data Migration

-- Create configuration table
CREATE TABLE application_config (
    config_key VARCHAR(255) NOT NULL,
    config_value TEXT NOT NULL,
    config_type VARCHAR(100) NOT NULL,
    environment VARCHAR(50) NOT NULL,
    description TEXT,
    encrypted BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (config_key, environment, config_type)
);

-- Sample data for datasource, Redis, Kafka, and business configurations (INSERT statements omitted for brevity)

Conclusion

Storing all configuration in a database adds system complexity, but in suitable scenarios it can dramatically improve operational efficiency and business agility by providing dynamic updates, centralized control, and fine‑grained versioning.

Reference: https://github.com/yuboon/java-examples/tree/master/springboot-db-cfg