Essential DataSource Properties in Spring Boot
Fast recall
Quick revision
Core answer
spring.datasource.url, spring.datasource.username, spring.datasource.password, and spring.datasource.driver-class-name (usually auto-detected from the URL). Spring Boot uses HikariCP as the default connection pool since Boot 2, so pool tuning lives under spring.datasource.hikari.* — maximum-pool-size, minimum-idle, connection-timeout, max-lifetime. For security, never commit passwords to properties files. Use environment-variable substitution — spring.datasource.password=${DB_PASSWORD} — and inject the real value from your secrets manager (Vault, AWS Secrets Manager, Kubernetes Secrets) at deploy time. Sizing follows the PgBouncer rule of thumb: max_pool_size ≈ (cores × 2) + effective_spindles — 10-20 connections per app instance, not 100.Whether you know the four essentials, understand Boot uses HikariCP by default, and handle secrets correctly (not hardcoded in VCS)
Hardcoding passwords; setting `maximum-pool-size` to 100+ thinking bigger pools are better; not knowing `driver-class-name` is optional because Boot infers it from the URL
Mention the connection-pool sizing formula, reference HikariCP's design rationale (smaller pools outperform large ones), and describe multi-datasource configuration with `@ConfigurationProperties`
Interview-ready guide
Interview answer
The four essential properties
- URL, username, password, and driver class name
- Driver is auto-detected from the URL, so usually omitted
HikariCP — the default pool since Boot 2
- Tuning prefix:
spring.datasource.hikari.* - Key knobs:
maximum-pool-size,minimum-idle,connection-timeout,max-lifetime
Trap 1: secrets in properties files
- Never commit passwords
- Use
${DB_PASSWORD}placeholder + inject at deploy time from Vault/AWS Secrets Manager/K8s Secrets
Trap 2: pool sizing — bigger is usually worse
- HikariCP author's rule (adapted from PgBouncer):
(cores × 2) + spindle_count - 4-core app + SSD → pool ~10
- A pool of 20 almost always beats a pool of 200 — beyond a threshold, DB context switches and lock contention destroy throughput
- Cloud DBs cap connections per instance — multiply pool size × replica count and verify you're under the cap
The hard-to-reproduce bug: `max-lifetime`
- Set
max-lifetimeslightly below the database's idle-connection timeout - Otherwise DB silently closes connections → intermittent failures under low traffic
Multiple datasources
- Separate prefixes:
app.datasource.primary.*,app.datasource.secondary.* - Bind via
@ConfigurationPropertiesin@Configurationclasses, mark one@Primary
Essential DataSource Properties in Spring Boot
Direct Answer
The four core properties are spring.datasource.url, spring.datasource.username, spring.datasource.password, and spring.datasource.driver-class-name (usually auto-detected from the URL). Spring Boot uses HikariCP as the default connection pool since Boot 2, so pool tuning lives under spring.datasource.hikari.* — maximum-pool-size, minimum-idle, connection-timeout, max-lifetime. For security, never commit passwords to properties files. Use environment-variable substitution — spring.datasource.password=${DB_PASSWORD} — and inject the real value from your secrets manager (Vault, AWS Secrets Manager, Kubernetes Secrets) at deploy time. Sizing follows the PgBouncer rule of thumb: max_pool_size ≈ (cores × 2) + effective_spindles — 10-20 connections per app instance, not 100.
Common Mistakes & Pitfalls
Hardcoding passwords; setting maximum-pool-size to 100+ thinking bigger pools are better; not knowing driver-class-name is optional because Boot infers it from the URL
Check your understanding
Answer these without looking back at the article.
- Why is HikariCP faster than Tomcat JDBC or Commons DBCP2?
- How would you investigate intermittent `Connection is closed` errors?
- What does `connection-test-query` do and when is it unnecessary?
- How do you handle DataSource credentials rotation without downtime?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.