1.4k stars · MIT · v7.1.0 (2026-08-24) · Track this in Scout
A job scheduler for PostgreSQL whose jobs and schedules live in the database itself.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You add a job by running a function inside the database, then run a small program that connects to that database and does the work when the time comes. Jobs can be SQL commands, programs on the machine, or built-in actions the project supplies, including sending email and downloading and importing a file. Several steps can be joined into a chain, so a download, an import and a clean-up run in order and stop if one fails. It uses cron-style timing, the same five-field pattern as the classic scheduler, and it can also read a chain written as YAML. Missed chains can be retried, which matters after a restart, and runs are logged into database tables rather than scattered across log files. It can refuse to start a chain that is already running, and chains and individual tasks can each be switched off without deleting them. OpenTelemetry export is there if you want run data sent somewhere else. The supported-versions table lists PostgreSQL 10 through 19, and the project says older versions should also work. It is a scheduler, not a workflow platform: there is no web page for drawing pipelines and no graphical editor.
Why it matters
Who it suits. Anyone who runs scheduled database work and has lost track of where the schedule lives. It suits a setup where one machine's crontab is the only record of what runs at night, because moving that record into the database makes it visible and restorable. It also suits work that must happen in a fixed order with a stop on failure, which plain cron cannot express. Skip it if you want a browser interface for building and watching pipelines, since this is deliberately a command and a set of tables.
Verdict. A good, narrow tool, and the narrowness is the point: it does one job and keeps its state where your backups already go. Two honest caveats. The documentation site is published at version 6.x while the newest tag is v7.1.0, so the pages may describe the previous line. And the release year could not be settled from here: the releases page shows v7.1.0 as 24 August with no year, and no second source available in this run would confirm it, so the day and month are all this edition will claim. Currency instead rests on the project's own supported-versions table listing PostgreSQL 19 in development, which only makes sense recently. If you would rather not run a separate program at all, citusdata/pg_cron lives entirely inside the database.
- The schedule is data in the database, so it is visible, editable and included in backups.
- Chains run several steps in order and stop on failure, which plain cron cannot do.
- Missed chains can be retried after downtime instead of being silently skipped.
- The documentation site is still on the 6.x line while the newest tag is v7.1.0.
- The release year could not be confirmed from the sources available here.
- One more program to keep running beside the database, with no web interface of its own.
- citusdata/pg_cron
Under the PostgreSQL Licence, it runs periodic jobs from inside PostgreSQL with nothing extra to install or keep running; simpler, but it cannot chain steps or run programs outside the database.
Track this in Scout 
dagucloud/daguGPL-3.0, a single-binary workflow runner with no database of its own, defined in YAML; a wider tool that also runs scripts, SSH commands and containers, and is not tied to PostgreSQL.
Track this in Scout
windmill-labs/windmillA much larger platform with a web interface that turns scripts into scheduled jobs, webhooks and small applications; covered in Edition 15, and it carries both AGPL-3.0 and Apache-2.0 files.
Track this in Scout
-- create a role the scheduler can use
CREATE ROLE scheduler WITH LOGIN CREATEDB PASSWORD 'change-me';
-- add one job: tidy up at 03:00 every night
SELECT timetable.add_job('nightly-vacuum', '0 3 * * *', 'VACUUM ANALYZE');