Spring Batch vs Plain JDBC Batch — When the Framework Earns Its Weight
Fast recall
Quick revision
Core answer
Whether you can articulate the operational features Spring Batch provides beyond batched SQL, and when those features justify the complexity
Reaching for Spring Batch for every batch task, including ones that are a single 30-second SQL statement — over-engineering
Frame the decision as restart-and-resume capability vs raw throughput — and mention that plain JDBC is often faster per-row because it avoids the JobRepository writes
Interview-ready guide
Interview answer
Plain JDBC and Spring Batch solve different problems. Plain JDBC's PreparedStatement.addBatch() is the right tool when you have a single SQL statement to repeat N times and failure means 'just re-run it'. Spring Batch is what you reach for when restart, audit, and skip/retry are operational requirements.
Plain JDBC wins on:
- Raw throughput per row — no framework overhead
- Code surface — 30 lines for a trivial batch task
- Simplicity — no JobRepository tables, no JobLauncher, no scope annotations
Spring Batch wins on:
- Restartability — a job that fails at 7M of 10M records resumes at 7M, not 0
- Skip and retry policies —
faultTolerant().skip(ParseException.class).skipLimit(100).retry(TransientDataAccessException.class).retryLimit(3)is one builder chain; hand-rolled equivalent is hundreds of lines - Audit trail — BATCH_JOB_EXECUTION and BATCH_STEP_EXECUTION show every run, parameters, and counts
- Partitioning — declarative parallel scale with per-partition restart
- Conditional flow —
start(validate).on("FAILED").to(alert).from(validate).on("*").to(import)is the DSL
Decision rule I use:
- Under 30 minutes, single statement, low stakes — plain JDBC with
JdbcTemplate.batchUpdateplus the right DB driver flags - Multi-hour, multi-step, must resume on failure — Spring Batch every time
- Adopting Spring Batch for trivial work is over-engineering; sticking with plain JDBC past the inflection point means rebuilding 70% of the framework poorly
In an interview, I'd lead with the framing that Spring Batch is not faster — it's more recoverable. Most candidates assume the framework brings performance; the real value is operational.
Spring Batch vs Plain JDBC Batch — When the Framework Earns Its Weight
Direct Answer
Plain JDBC PreparedStatement.addBatch() is the right tool when the job is a single SQL statement repeated N times inside one process and you don't need restart, audit, or skip/retry. Spring Batch earns its weight when you need restartability from the last checkpoint, a JobRepository audit trail, skip and retry policies for bad records and transient errors, partitioning for parallel scale, or composition of multiple steps with conditional flow. The rough rule: if your batch is under a few minutes, single-statement, and never fails — use plain JDBC. If it processes millions of records over hours and a midnight failure must resume at 7 AM rather than restart from zero — use Spring Batch.
Common Mistakes & Pitfalls
Reaching for Spring Batch for every batch task, including ones that are a single 30-second SQL statement — over-engineering
Check your understanding
Answer these without looking back at the article.
- What MySQL/PostgreSQL JDBC driver flag is essential for batch insert performance, and why?
- How would you migrate a hand-rolled JDBC batch job to Spring Batch incrementally?
- What overhead does the JobRepository add per chunk, and how do you minimize it?
- When would you reach for Spring Cloud Data Flow rather than plain Spring Batch?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.