Introduction

Spring Boot accepts both application.properties and application.yml, and the database settings are the same logical keys in either format. Converting to YAML is mainly about translating flat dotted keys into nested structure while preserving the same meaning. Once the hierarchy is clear, database configuration in application.yml is usually easier to read and maintain than a long properties file.

Convert Flat Properties into Nested YAML

A common application.properties database setup looks like this:

1spring.datasource.url=jdbc:postgresql://localhost:5432/appdb
2spring.datasource.username=appuser
3spring.datasource.password=secret
4spring.datasource.driver-class-name=org.postgresql.Driver
5spring.jpa.hibernate.ddl-auto=validate
6spring.jpa.show-sql=true
7spring.jpa.properties.hibernate.format_sql=true

The YAML equivalent is:

1spring:
2  datasource:
3    url: jdbc:postgresql://localhost:5432/appdb
4    username: appuser
5    password: secret
6    driver-class-name: org.postgresql.Driver
7  jpa:
8    hibernate:
9      ddl-auto: validate
10    show-sql: true
11    properties:
12      hibernate:
13        format_sql: true

That is the main conversion rule:

• dotted segments become nested YAML keys
• scalar values stay scalar values
• indentation matters

The property names themselves do not change, only the representation.

Include Connection Pool Settings

If your application uses the default Hikari connection pool, those settings also move under spring.datasource.hikari.

1spring:
2  datasource:
3    url: jdbc:mysql://localhost:3306/appdb
4    username: appuser
5    password: secret
6    driver-class-name: com.mysql.cj.jdbc.Driver
7    hikari:
8      maximum-pool-size: 10
9      minimum-idle: 2
10      connection-timeout: 30000

This structure is easier to scan than the properties equivalent because all datasource and pool configuration stays visually grouped.

Keep Environment-Specific Settings Separate

YAML becomes especially useful when you want profile-specific sections. For example:

1spring:
2  datasource:
3    url: jdbc:postgresql://localhost:5432/appdb
4    username: appuser
5    password: local-secret
6
7---
8spring:
9  config:
10    activate:
11      on-profile: prod
12  datasource:
13    url: jdbc:postgresql://prod-db:5432/appdb
14    username: produser
15    password: prod-secret

That lets one file express shared defaults and profile overrides clearly. For sensitive production credentials, however, environment variables or a secret manager are usually better than hardcoding secrets into the file.

Use Placeholders for Externalized Secrets

A practical YAML setup often combines defaults with environment placeholders:

1spring:
2  datasource:
3    url: ${DB_URL:jdbc:postgresql://localhost:5432/appdb}
4    username: ${DB_USERNAME:appuser}
5    password: ${DB_PASSWORD:secret}
6    driver-class-name: org.postgresql.Driver

This means:

• use the environment value if present
• otherwise fall back to the provided default

That makes local development easy without giving up deploy-time configurability.

Watch YAML Syntax Carefully

Most migration errors are not Spring Boot issues. They are YAML syntax errors:

• wrong indentation
• tabs instead of spaces
• misplaced profile separators
• accidentally turning a scalar into a nested object

For example, this is wrong:

spring:
datasource:
  url: jdbc:postgresql://localhost:5432/appdb

because datasource is no longer nested under spring.

When configuration suddenly stops binding after conversion, inspect indentation first. Spring property binding is usually fine; malformed YAML is the more common cause.

Validate the Migration with a Simple Startup

After converting, run the application and verify that the datasource actually binds:

1import org.springframework.boot.CommandLineRunner;
2import org.springframework.stereotype.Component;
3
4import javax.sql.DataSource;
5
6@Component
7public class DataSourceCheck implements CommandLineRunner {
8    private final DataSource dataSource;
9
10    public DataSourceCheck(DataSource dataSource) {
11        this.dataSource = dataSource;
12    }
13
14    @Override
15    public void run(String... args) {
16        System.out.println(dataSource.getClass().getName());
17    }
18}

This is a simple sanity check that the app still creates the datasource after the format change.

Common Pitfalls

• Translating dotted property names incorrectly and breaking the nesting structure.
• Misplacing indentation and assuming Spring Boot is the problem instead of YAML syntax.
• Hardcoding secrets in application.yml when environment placeholders would be safer.
• Mixing profile-specific and shared values without clear separators.
• Changing property names during conversion even though only the format needed to change.

Summary

• Converting database config from properties to YAML is mostly a structural transformation.
• Dotted keys become nested YAML sections under the same logical property names.
• 'spring.datasource and spring.jpa settings map cleanly into YAML.'
• YAML is especially helpful for grouping related database and profile-specific settings.
• Validate the conversion with a real application startup so syntax and binding problems are caught early.