schedule_job in ParadeDB lets you run named SQL tasks on a cron-like schedule inside PostgreSQL.
schedule_job
in ParadeDB?schedule_job
is a ParadeDB helper that wraps pg_cron
under a simple API so you can automate SQL tasks—refreshing materialized views, sending reports, or cleaning data—without leaving PostgreSQL.
Automating nightly inventory syncs, daily revenue rollups, or customer-email exports removes manual steps, guarantees consistency, and lowers operational overhead.
Call parade.schedule_job
with a unique name, SQL to run, a cron string, and optional JSON settings. ParadeDB stores the job in parade.jobs
and registers it with pg_cron
.
The query below refreshes the daily_sales_mv
materialized view at 01:00 every day.
SELECT parade.schedule_job(
'refresh_daily_sales',
$$ REFRESH MATERIALIZED VIEW CONCURRENTLY daily_sales_mv; $$,
'0 1 * * *',
'{"owner":"analytics"}'::jsonb
);
Query parade.jobs
or call parade.show_jobs()
to see name, schedule, last_run, and next_run.
Use parade.alter_job(job_name, new_cron, new_sql, new_config)
to edit, or parade.disable_job(job_name)
to stop it without deletion.
Keep job SQL idempotent, monitor runtime in parade.job_run_history
, and log errors with RAISE
to capture failures quickly.
Using NOW()
instead of current_date
in daily jobs causes multiple dates in one run window. Use current_date
for date-based inserts.
Overlapping schedules create lock contention. Stagger heavy jobs or use CONCURRENTLY
options.
Check pg_cron
documentation for advanced cron patterns and ParadeDB GitHub for job management helpers.
Call parade.alter_job('job_name', '30 2 * * *')
; the change is immediate.
Yes. Execute parade.run_job('job_name')
to trigger it instantly.
Use SELECT * FROM parade.job_run_history WHERE job_name='job_name'
for execution history and errors.
Run parade.alter_job('job_name', '30 2 * * *')
; changes apply immediately.
Yes. Call parade.run_job('job_name')
to execute it on demand.
Query parade.job_run_history
to inspect start time, end time, and errors for each run.