iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
db-scheduler is a Java library for running one-time and recurring background tasks whose execution state is stored in a relational database. Multiple application instances can share that database and coordinate task pickup, so work can survive process restarts without relying on one JVM’s in-memory timer. It is a fit when database-backed persistence and straightforward clustered scheduling matter more than exact-time execution or guaranteed catch-up of every recurrence.
How db-scheduler persists and coordinates work
The project describes db-scheduler as an embeddable alternative for clustered scheduling inspired by java.util.concurrent.ScheduledExecutorService. It tracks executions in one relational database table, typically scheduled_tasks. Scheduler instances poll for due work, claim an execution, run its task, and then determine the next execution from the task’s schedule or handler. Depending on the polling strategy, claiming uses optimistic locking or select-for-update to prevent two instances from picking the same execution.
This makes the database part of the scheduler’s runtime design: it stores pending execution state and supports coordination, rather than serving merely as the task’s business-data store. The project describes db-scheduler as minimally dependent and reports production use by organizations including Digipost and Wise; those are project-reported examples, not independent endorsements. See the project documentation.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteWhat you need before adopting it
- Java: The project documentation states Java 17 or later is required.
- Database: You need a supported relational database and the scheduler table. The project lists PostgreSQL, SQL Server, MySQL, MariaDB, Oracle, SQLite, and HSQLDB.
- Schema and database-specific setup: Database engines differ in fetch and locking support, timestamp handling, and schema details. Check the current compatibility table and schema instructions for your exact engine and version before deployment.
- Version: The official releases page showed v16.12.0 as latest when checked for this article. The README’s example dependency still shows 16.11.0, so use the release page or published artifact metadata to select a current version rather than copying that example.
The README’s compatibility table separates generic fetch from lock-and-fetch support. PostgreSQL and SQL Server support both; MySQL 8+ is also listed for both. Other databases in the table are marked fetch-only. The project also calls out database-specific timestamp requirements, including UTC persistence for MySQL/MariaDB and timestamp-type guidance for Oracle. These details make database/version verification important: a database appearing on the supported list does not mean every locking mode or configuration applies to it. Check current releases and notes and consult the database compatibility and setup documentation.
What kinds of schedules it supports
Tasks can be one-time or recurring. Recurring schedules can be defined statically or persisted dynamically at runtime. Documented schedule types include fixed delay, daily execution with an optional time zone, and Spring-style cron expressions. The SchedulerClient can list, schedule, reschedule, or remove persisted executions, giving applications a programmatic way to inspect and manage them.
Does it guarantee every run at the scheduled time?
No. db-scheduler polls the database, so execution timing depends in part on the polling interval. The README documents defaults of 10 scheduler threads and a 10-second polling interval; unless an early check is triggered, due work is discovered on the configured polling cycle. These defaults are configurable, and polling more often can improve responsiveness while increasing database checks.
Rank #2
More importantly, persistence does not mean that every nominal recurrence is replayed. The project states: “There are no guarantees that all instants in a schedule for a RecurringTask will be executed.” The next time is calculated after the previous task finishes. A slow or prolonged execution can therefore shift subsequent runs rather than produce a backlog containing every missed instant. If the requirement is strict wall-clock timing, complete catch-up, or precise interval accounting, verify that behavior against your needs and model missed work explicitly in the task or another system.
How failures and restarts are handled
Task failures
By default, recurring tasks are rescheduled according to their schedule after failure, while one-time tasks retry after five minutes. Treat these as documented defaults, not a substitute for defining idempotency, alerting, and business-level recovery. A retried task may encounter data changes made before its earlier attempt failed.
Executions left behind by a stopped process
An execution may be considered dead when its heartbeat is stale, such as after a JVM exits unexpectedly. A configurable dead-execution handler handles these cases; the documented default revives the execution by rescheduling it for now. This recovery behavior supports restart resilience, but it does not itself prove that a task’s external side effects are safe to repeat.
Task data compatibility
Task data is serialized. Java serialization is the default, and the project documents Gson, Jackson, and Kotlin options. Because persisted data can outlive a deployment, plan how serialized task-data classes will remain readable as application versions change. Test upgrades against executions that were created by the previous version, especially when changing class structure or serialization configuration.
Rank #4
Spring Boot integration
The project provides Spring Boot starter modules and documents exposing task definitions as beans. It distinguishes a starter for Spring Boot 3.x from a Boot 4 starter, and describes optional health information and configuration through properties or override beans. Choose the starter that matches your Boot line and confirm the latest project instructions for compatibility before wiring it into an application. The README contains the current integration guidance.
Recommended Free Tools
How to evaluate it against Quartz or an in-memory scheduler
db-scheduler’s stated aim is simpler clustered scheduling with less database-schema overhead than Quartz. That is the project’s framing, not an independently established ranking. The useful comparison is how each option fits your operational requirements:
Best Value
- Persistence and coordination: db-scheduler stores execution state in a relational table shared by instances. An in-memory scheduled executor does not provide that persistence model by itself.
- Database and locking: db-scheduler introduces a database dependency and engine-specific compatibility considerations. Confirm the fetch/locking mode supported by your chosen database.
- Timing and catch-up: polling affects responsiveness, and recurring executions do not guarantee every scheduled instant will run. If exact timing or full catch-up is essential, make that a deciding criterion.
- Recovery and administration: account for retry and dead-execution behavior, and determine whether the SchedulerClient’s listing and management operations are sufficient for your operational workflow.
- Framework fit: Spring Boot starters can reduce integration work, but compatibility must match the Boot version in use.
- Schema and maintenance: assess the cost of maintaining the scheduler table, database configuration, and task-data compatibility across releases.
How to interpret the project’s throughput claim
The README says db-scheduler is “Tested to handle 2k – 10k executions / second.” The project passage does not include a publication year, workload description, or benchmark methodology. Treat this as a project-reported claim, not an independently verified capacity estimate or a prediction for your database and tasks. Measure your own workload and deployment configuration before using throughput as an adoption criterion. Read the project README.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
