How to Schedule Jobs in PostgreSQL with pg_cron

<p>Every backend system eventually needs something to run on a schedule. Old sessions need deleting, summary tables need rebuilding, materialized views need refreshing, and maintenance tasks need to happen while everyone is asleep.</p> <p>The usual answer is to reach outside the database: a system crontab, a Kubernetes CronJob, a Celery beat worker, or a scheduler service. All of these work, but they add moving parts. Now you have credentials to manage, a separate process to monitor, and one more thing that can silently stop running.</p> <p>pg_cron takes a different approach. It's a PostgreSQL extension that runs a cron-style scheduler <em>inside</em> the database itself. You schedule jobs with plain SQL, the database executes them, and the run history lands in a table you can query like anything else.</p> <p>In this tutorial, you'll learn how pg_cron works, how to install and configure it, and how to use it for real maintenance tasks. You'll also learn how to monitor jobs, manage permissions, and decide when pg_cron is the right tool — and when it isn't.</p> <h2 id="heading-table-of-contents">Table of Contents</h2> <ul> <li><p><a href="#heading-prerequisites">Prerequisites</a></p> </li> <li><p><a href="#heading-what-is-pgcron">What Is pg_cron?</a></p> </li> <li><p><a href="#heading-how-pgcron-works">How pg_cron Works</a></p> </li> <li><p><a href="#heading-how-to-install-and-set-up-pgcron">How to Install and Set Up pg_cron</a></p> </li> <li><p><a href="#heading-a-quick-refresher-on-cron-syntax">A Quick Refresher on Cron Syntax</a></p> </li> <li><p><a href="#heading-how-to-schedule-your-first-job">How to Schedule Your First Job</a></p> </li> <li><p><a href="#heading-practical-pgcron-examples">Practical pg_cron Examples</a></p> </li> <li><p><a href="#heading-how-to-view-and-monitor-your-jobs">How to View and Monitor Your Jobs</a></p> </li> <li><p><a href="#heading-how-to-update-and-remove-jobs">How to Update and Remove Jobs</a></p> </li> <li><p><a href="#heading-how-to-run-jobs-in-other-databases">How to Run Jobs in Other Databases</a></p> </li> <li><p><a href="#heading-how-to-let-other-users-schedule-jobs">How to Let Other Users Schedule Jobs</a></p> </li> <li><p><a href="#heading-when-to-use-pgcron-and-when-to-avoid-it">When to Use pg_cron (and When to Avoid It)</a></p> </li> <li><p><a href="#heading-best-practices-for-working-with-pgcron">Best Practices for Working with pg_cron</a></p> </li> <li><p><a href="#heading-conclusion">Conclusion</a></p> </li> </ul> <h2 id="heading-prerequisites">Prerequisites</h2> <p>To follow along with the examples, you'll need:</p> <ul> <li><p>Basic knowledge of SQL (SELECT, INSERT, UPDATE, DELETE)</p> </li> <li><p>A running PostgreSQL instance (version 13 or later is ideal, though pg_cron supports version 10 and up)</p> </li> <li><p>Superuser or admin access to that instance, since installing the extension requires it</p> </li> <li><p>A SQL client like <code>psql</code>, pgAdmin, or DBeaver</p> </li> </ul> <p>If you don't run your own server, that's fine too. Most managed PostgreSQL services — including Amazon RDS, Azure Database for PostgreSQL, Google Cloud SQL, Supabase, and Neon — support pg_cron. I'll cover how to enable it on those later in the tutorial.</p> <h2 id="heading-what-is-pgcron">What Is pg_cron?</h2> <p>pg_cron is an open source PostgreSQL extension, originally built by the team at Citus Data, that lets you schedule SQL commands using the familiar cron syntax.</p> <p>Instead of writing a crontab entry on a server, you write a SQL statement:</p> <pre><code class="language-sql">SELECT cron.schedule( 'nightly-cleanup', '0 3 * * *', $$DELETE FROM sessions WHERE expires_at &lt; now()$$ ); </code></pre> <p>That single statement tells PostgreSQL to delete expired sessions every day at 3 AM. No external process, no shell script, no extra credentials. The job definition lives in the database, version-controlled alongside your migrations if you want it to be.</p> <p>Because the scheduler is just another extension, your jobs travel with the database. Anyone who can connect and query can see exactly what's scheduled, when it last ran, and whether it succeeded.</p> <h2 id="heading-how-pgcron-works">How pg_cron Works</h2> <p>When PostgreSQL starts with pg_cron enabled, the extension launches a background worker. This worker has one job: watch the <code>cron.job</code> table, which holds every scheduled job along with its schedule, command, target database, and the user it runs as.</p> <p>When a job's scheduled time arrives, the worker executes the command. By default it does this by opening a new local connection to the database, just as your application would. You can also configure it to use PostgreSQL background workers instead of connections, which I'll show you in the setup section.</p> <p>Two behaviors are worth knowing up front:</p> <p>First, pg_cron can run many <em>different</em> jobs in parallel, but it never runs two instances of the <em>same</em> job at once. If a job is still running when its next scheduled time arrives, the new run waits in a queue and starts as soon as the current one finishes. This protects you from a slow cleanup job piling up on top of itself.</p> <p>Second, pg_cron doesn't run jobs while a server is in hot standby mode. If you use streaming replication, jobs only execute on the primary. When a replica gets promoted, the scheduler starts up automatically — so failover doesn't leave you without your scheduled jobs.</p> <h2 id="heading-how-to-install-and-set-up-pgcron">How to Install and Set Up pg_cron</h2> <p>Setting up pg_cron on a self-managed server takes three steps: install the package, update the configuration, and create the extension.</p> <h3 id="heading-step-1-install-the-package">Step 1: Install the Package</h3> <p>On Debian or Ubuntu using the official PostgreSQL apt repository, install the package that matches your PostgreSQL major version. For PostgreSQL 17, that's:</p> <pre><code class="language-bash">sudo apt-get install postgresql-17-cron </code></pre> <p>On Red Hat-based systems using the PGDG yum repository:</p> <pre><code class="language-bash">sudo yum install pg_cron_17 </code></pre> <p>If you're on PostgreSQL 16 or 18, swap the version number accordingly. You can also build the extension from source if your platform doesn't have a package.</p> <h3 id="heading-step-2-update-postgresqlconf">Step 2: Update postgresql.conf</h3> <p>pg_cron needs to start its background worker when PostgreSQL boots, so it must be preloaded. Add it to <code>shared_preload_libraries</code> in your <code>postgresql.conf</code>:</p> <pre><code class="language-ini">shared_preload_libraries = 'pg_cron' </code></pre> <p>If that setting already lists other libraries, add pg_cron to the comma-separated list rather than replacing them.</p> <p>By default, the scheduler stores its metadata in the database named <code>postgres</code>. If your application lives in a different database and you want the jobs there, set:</p> <pre><code class="language-ini">cron.database_name = 'app_db' </code></pre> <p>One more setting worth knowing: pg_cron interprets all schedules in GMT by default. If you want your "3 AM cleanup" to actually run at 3 AM local time, set the timezone explicitly:</p> <pre><code class="language-ini">cron.timezone = 'Africa/Lagos' </code></pre> <p>These settings require a server restart to take effect:</p> <pre><code class="language-bash">sudo systemctl restart postgresql </code></pre> <h3 id="heading-step-3-create-the-extension">Step 3: Create the Extension</h3> <p>Connect to the database you configured in <code>cron.database_name</code> and create the extension as a superuser:</p> <pre><code class="language-sql">CREATE EXTENSION pg_cron; </code></pre> <p>This creates the <code>cron</code> schema, the metadata tables, and the scheduling functions. You're ready to schedule jobs.</p> <p>Note that pg_cron can only be <em>installed</em> in one database per PostgreSQL instance. That sounds limiting, but it isn't. You can still run jobs in any database on the instance using <code>cron.schedule_in_database()</code>, which we'll cover later.</p> <h3 id="heading-a-note-on-how-jobs-connect">A Note on How Jobs Connect</h3> <p>Since pg_cron opens local connections by default, your <code>pg_hba.conf</code> needs to allow them. The common approaches are enabling <code>trust</code> authentication for localhost connections for the job's user, or putting the password in a <code>.pgpass</code> file.</p> <p>If you'd rather avoid connection authentication entirely, tell pg_cron to use background workers instead:</p> <pre><code class="language-ini">cron.use_background_workers = on max_worker_processes = 20 </code></pre> <p>With background workers, the number of jobs that can run concurrently is capped by <code>max_worker_processes</code>, so raise it if you schedule a lot of overlapping jobs.</p> <h3 id="heading-using-pgcron-on-managed-database-services">Using pg_cron on Managed Database Services</h3> <p>If you're on a managed service, you usually can't edit <code>postgresql.conf</code> directly, but the providers expose the same settings through their own mechanisms:</p> <ul> <li><p><strong>Amazon RDS and Aurora PostgreSQL</strong>: add <code>pg_cron</code> to the <code>shared_preload_libraries</code> parameter in your DB parameter group, reboot the instance, then run <code>CREATE EXTENSION pg_cron;</code> as a user with <code>rds_superuser</code>. The scheduler runs in the <code>postgres</code> database.</p> </li> <li><p><strong>Azure Database for PostgreSQL</strong>: enable pg_cron under server parameters (<code>shared_preload_libraries</code> and <code>azure.extensions</code>), restart, then create the extension.</p> </li> <li><p><strong>Google Cloud SQL</strong>: set the <code>cloudsql.enable_pg_cron</code> flag, restart, then create the extension.</p> </li> <li><p><strong>Supabase</strong>: enable the pg_cron extension with a single toggle in the dashboard under Database → Extensions.</p> </li> <li><p><strong>Neon</strong>: pg_cron is available as a supported extension you can enable per project.</p> </li> </ul> <p>The SQL you write afterward is identical everywhere, which is part of the appeal.</p> <h2 id="heading-a-quick-refresher-on-cron-syntax">A Quick Refresher on Cron Syntax</h2> <p>pg_cron uses the same five-field schedule format as classic Unix cron:</p> <pre><code class="language-plaintext">┌──────────── minute (0–59) │ ┌────────── hour (0–23) │ │ ┌──────── day of month (1–31, or $ for the last day) │ │ │ ┌────── month (1–12) │ │ │ │ ┌──── day of week (0–6, Sunday = 0) │ │ │ │ │ * * * * * </code></pre> <p>An asterisk means "every value". You can combine values with commas, ranges with hyphens, and steps with slashes. Some schedules you'll use constantly:</p> <pre><code class="language-plaintext">*/5 * * * * every 5 minutes 0 * * * * every hour, on the hour 0 3 * * * every day at 3:00 AM 0 3 * * 1-5 3:00 AM on weekdays 30 1 * * 0 1:30 AM every Sunday 0 0 1 * * midnight on the 1st of each month </code></pre> <p>pg_cron also adds two extensions to the standard syntax that regular cron doesn't have.</p> <p>You can use <code>$</code> in the day-of-month field to mean the last day of the month, which is genuinely painful to express in standard cron:</p> <pre><code class="language-plaintext">0 23 $ * * 11:00 PM on the last day of every month </code></pre> <p>And for jobs that need to run more often than once a minute, you can use a plain interval between 1 and 59 seconds:</p> <pre><code class="language-plaintext">'30 seconds' every 30 seconds </code></pre> <p>The seconds syntax stands alone — you can't mix it with the five-field format.</p> <p>If you ever doubt what a schedule means, <a href="https://crontab.guru">crontab.guru</a> translates cron expressions into plain English. Just remember that pg_cron evaluates schedules in the timezone set by <code>cron.timezone</code>, which defaults to GMT.</p> <h2 id="heading-how-to-schedule-your-first-job">How to Schedule Your First Job</h2> <p>The core function is <code>cron.schedule()</code>. It comes in two forms: one with a name and one without.</p> <p>The named form is the one you should use, because names make jobs easy to find, update, and remove:</p> <pre><code class="language-sql">SELECT cron.schedule( 'delete-expired-sessions', -- job name '0 3 * * *', -- schedule $$DELETE FROM sessions WHERE expires_at &lt; now()$$ -- command ); </code></pre> <p>The function returns the job's ID:</p> <pre><code class="language-plaintext"> schedule ---------- 1 (1 row) </code></pre> <p>A few details worth noticing:</p> <p>The command is wrapped in <code>$$ ... $$</code>, PostgreSQL's dollar quoting. This saves you from escaping the single quotes inside the SQL. For commands without quotes, regular string literals work fine.</p> <p>The job runs in the database where you called <code>cron.schedule()</code>, as the user you called it with, using that user's normal permissions. There's no privilege escalation hiding in the scheduler — if your user can't delete from <code>sessions</code>, neither can the job.</p> <p>And if you call <code>cron.schedule()</code> again with the same job name, pg_cron updates the existing job instead of creating a duplicate. That makes schedules idempotent, which is handy if you define jobs inside database migrations.</p> <h2 id="heading-practical-pgcron-examples">Practical pg_cron Examples</h2> <p>Let's walk through the patterns that cover most real-world use. Each example is something you can adapt directly.</p> <h3 id="heading-example-1-clean-up-old-rows-every-night">Example 1: Clean Up Old Rows Every Night</h3> <p>Tables that collect transient data — sessions, tokens, audit events, notification logs — grow forever unless something prunes them. A nightly delete is the classic first pg_cron job:</p> <pre><code class="language-sql">SELECT cron.schedule( 'purge-old-events', '0 2 * * *', $$DELETE FROM events WHERE created_at &lt; now() - interval '90 days'$$ ); </code></pre> <p>Every night at 2:00 AM, rows older than 90 days disappear. If the table is large, consider batching the delete inside a function so each run stays short, then schedule the function instead.</p> <h3 id="heading-example-2-refresh-a-materialized-view-every-hour">Example 2: Refresh a Materialized View Every Hour</h3> <p>Materialized views are a great way to cache expensive aggregations, but PostgreSQL never refreshes them on its own. pg_cron fixes that:</p> <pre><code class="language-sql">SELECT cron.schedule( 'refresh-daily-sales', '5 * * * *', 'REFRESH MATERIALIZED VIEW CONCURRENTLY daily_sales_summary' ); </code></pre> <p>This refreshes the view at five minutes past every hour. The <code>CONCURRENTLY</code> option lets reads continue during the refresh, as long as the view has a unique index.</p> <h3 id="heading-example-3-build-a-daily-summary-table">Example 3: Build a Daily Summary Table</h3> <p>Rollup tables are another common pattern: instead of aggregating millions of raw rows on every dashboard load, you precompute the numbers once a day.</p> <pre><code class="language-sql">SELECT cron.schedule( 'rollup-daily-orders', '15 0 * * *', $$ INSERT INTO daily_order_stats (day, order_count, total_amount) SELECT created_at::date, count(*), sum(amount) FROM orders WHERE created_at &gt;= current_date - 1 AND created_at &lt; current_date GROUP BY created_at::date ON CONFLICT (day) DO UPDATE SET order_count = EXCLUDED.order_count, total_amount = EXCLUDED.total_amount $$ ); </code></pre> <p>At fifteen minutes past midnight, yesterday's orders get summarized into one row. The <code>ON CONFLICT</code> clause makes the job safe to re-run — if it executes twice, it overwrites rather than duplicates.</p> <h3 id="heading-example-4-run-a-job-every-30-seconds">Example 4: Run a Job Every 30 Seconds</h3> <p>Some work needs to happen more often than cron's one-minute floor allows: flushing a buffer table, picking up rows from an outbox, advancing a lightweight queue. The seconds syntax handles this:</p> <pre><code class="language-sql">SELECT cron.schedule( 'process-outbox', '30 seconds', 'CALL process_outbox_batch()' ); </code></pre> <p>Remember the guarantee from earlier: pg_cron won't start a second instance of this job while the first is still running. If a batch occasionally takes 45 seconds, the next run simply waits its turn instead of stampeding.</p> <h3 id="heading-example-5-run-maintenance-on-the-last-day-of-the-month">Example 5: Run Maintenance on the Last Day of the Month</h3> <p>Month-end jobs are awkward in standard cron because months have different lengths. pg_cron's <code>$</code> makes it trivial:</p> <pre><code class="language-sql">SELECT cron.schedule( 'month-end-vacuum', '0 23 $ * *', 'VACUUM ANALYZE orders' ); </code></pre> <p>This runs <code>VACUUM ANALYZE</code> on the <code>orders</code> table at 11:00 PM on the 28th, 29th, 30th, or 31st — whichever happens to be the last day of that month.</p> <h2 id="heading-how-to-view-and-monitor-your-jobs">How to View and Monitor Your Jobs</h2> <p>Everything pg_cron knows lives in two tables in the <code>cron</code> schema, and you query them like any other tables.</p> <p>To see what's scheduled, look at <code>cron.job</code>:</p> <pre><code class="language-sql">SELECT jobid, jobname, schedule, command, active FROM cron.job; </code></pre> <pre><code class="language-plaintext"> jobid | jobname | schedule | command | active -------+-------------------------+------------+--------------------------------+-------- 1 | delete-expired-sessions | 0 3 * * * | DELETE FROM sessions WHERE ... | t 2 | refresh-daily-sales | 5 * * * * | REFRESH MATERIALIZED VIEW ... | t (2 rows) </code></pre> <p>To see how jobs have actually been running, query <code>cron.job_run_details</code>:</p> <pre><code class="language-sql">SELECT jobid, status, return_message, start_time, end_time FROM cron.job_run_details ORDER BY start_time DESC LIMIT 10; </code></pre> <p>Each row records one execution: whether it succeeded or failed, the message it returned, and exactly when it started and ended. A failed job shows <code>status = 'failed'</code> along with the error message, so debugging usually starts and ends with this table.</p> <p>One important catch: <strong>pg_cron never cleans this table up by itself</strong>. A job running every 30 seconds writes almost three thousand rows a day. The standard fix is delightfully recursive — schedule a pg_cron job to prune pg_cron's own history:</p> <pre><code class="language-sql">SELECT cron.schedule( 'purge-cron-history', '0 12 * * *', $$DELETE FROM cron.job_run_details WHERE end_time &lt; now() - interval '14 days'$$ ); </code></pre> <p>If you don't want run history recorded at all, set <code>cron.log_run = off</code> in your configuration.</p> <h2 id="heading-how-to-update-and-remove-jobs">How to Update and Remove Jobs</h2> <p>To change an existing job, use <code>cron.alter_job()</code> with the job's ID. Only the parameters you pass get changed — everything else stays as it was:</p> <pre><code class="language-sql">-- Move job 1 from 3 AM to 4 AM SELECT cron.alter_job(1, schedule := '0 4 * * *'); -- Pause a job without deleting it SELECT cron.alter_job(1, active := false); -- Resume it later SELECT cron.alter_job(1, active := true); </code></pre> <p>Pausing with <code>active := false</code> is underrated. During an incident or a big migration, you can switch off a noisy job and switch it back on afterward, without losing its definition.</p> <p>To remove a job permanently, use <code>cron.unschedule()</code> with either the name or the ID:</p> <pre><code class="language-sql">SELECT cron.unschedule('delete-expired-sessions'); -- or SELECT cron.unschedule(1); </code></pre> <p>Both return <code>true</code> when the job was found and removed.</p> <h2 id="heading-how-to-run-jobs-in-other-databases">How to Run Jobs in Other Databases</h2> <p>Remember that pg_cron is installed in exactly one database per instance, usually <code>postgres</code>. If your instance hosts several databases, you don't install pg_cron in each one — you schedule cross-database jobs from the one place it lives, using <code>cron.schedule_in_database()</code>:</p> <pre><code class="language-sql">SELECT cron.schedule_in_database( 'analytics-nightly-vacuum', '0 4 * * *', 'VACUUM ANALYZE page_views', 'analytics_db' ); </code></pre> <p>The job is stored centrally but executes inside <code>analytics_db</code>. The function also accepts an optional username if the job should run as a different user, and an <code>active</code> flag if you want to create it paused.</p> <p>This pattern keeps all scheduling in one schema on one database, which makes auditing simple: a single <code>SELECT * FROM cron.job</code> shows every scheduled job across the whole instance.</p> <h2 id="heading-how-to-let-other-users-schedule-jobs">How to Let Other Users Schedule Jobs</h2> <p>Out of the box, only superusers can call the scheduling functions. To let an application role manage its own jobs, grant it usage on the <code>cron</code> schema:</p> <pre><code class="language-sql">GRANT USAGE ON SCHEMA cron TO app_user; </code></pre> <p>The permission model after that is sensible and safe:</p> <ul> <li><p>Jobs run with the permissions of the user who scheduled them, nothing more.</p> </li> <li><p>A row-level security policy on <code>cron.job</code> means users only see and modify their own jobs. Superusers see everything.</p> </li> <li><p>Each user can also delete their own rows from <code>cron.job_run_details</code>, so the cleanup job from earlier works without superuser rights.</p> </li> </ul> <p>In practice, I recommend creating a dedicated role for scheduled work rather than scheduling jobs as a personal account. When the engineer who scheduled everything leaves and their role gets dropped, you don't want the nightly rollups going with them.</p> <h2 id="heading-when-to-use-pgcron-and-when-to-avoid-it">When to Use pg_cron (and When to Avoid It)</h2> <p>pg_cron shines when the work is <em>database work</em>. Use it for:</p> <ul> <li><p><strong>Data retention</strong>: pruning old rows from sessions, logs, events, and token tables.</p> </li> <li><p><strong>Aggregations</strong>: refreshing materialized views and building rollup tables.</p> </li> <li><p><strong>Maintenance</strong>: targeted <code>VACUUM ANALYZE</code>, rebuilding statistics, managing partitions (it pairs beautifully with pg_partman).</p> </li> <li><p><strong>Lightweight pipelines</strong>: moving rows between tables, processing outbox patterns, expiring soft-deleted records.</p> </li> </ul> <p>The common thread: the entire job is expressible as SQL or a stored procedure, and it touches nothing outside the database.</p> <p>You should reach for something else when:</p> <ul> <li><p><strong>The job needs to call external systems.</strong> pg_cron runs SQL. It can't send an HTTP request, push to a queue, or send an email on its own. Jobs like that belong in your application or a workflow engine.</p> </li> <li><p><strong>You need retries, backoff, and alerting built in.</strong> pg_cron records failures but won't retry them or page you. For workflows that must complete, tools like Temporal or a proper job queue earn their complexity.</p> </li> <li><p><strong>The work is heavy and long-running.</strong> A four-hour batch job running inside your primary OLTP database competes with your application for CPU, memory, and locks. Schedule heavy compute elsewhere.</p> </li> <li><p><strong>Jobs need complex dependencies.</strong> "Run B only after A succeeds, then fan out to C and D" is orchestration. That's Airflow territory, not cron territory.</p> </li> </ul> <p>A reasonable rule of thumb: pg_cron replaces the crontab entry that used to run <code>psql -c "..."</code> on some forgotten server. It doesn't replace your job queue or your workflow orchestrator.</p> <h2 id="heading-best-practices-for-working-with-pgcron">Best Practices for Working with pg_cron</h2> <p>A handful of habits will keep your scheduled jobs boring, in the best sense of the word:</p> <p><strong>Name every job:</strong> Anonymous jobs identified only by an ID are painful to manage six months later. Names also make <code>cron.schedule()</code> idempotent, which lets you define jobs safely in migrations.</p> <p><strong>Set the timezone deliberately:</strong> The default is GMT, and "why does the 3 AM job run at 4 AM?" is a rite of passage you can skip by setting <code>cron.timezone</code> on day one.</p> <p><strong>Keep individual runs short:</strong> Wrap big deletes in batched stored procedures. A job that finishes in seconds holds locks briefly and queues less behind itself.</p> <p><strong>Make jobs idempotent:</strong> Servers restart, and a job can fail halfway. Use <code>ON CONFLICT</code>, time-window predicates, and other patterns that make a re-run harmless.</p> <p><strong>Prune</strong> <code>cron.job_run_details</code><strong>:</strong> Schedule the cleanup job from the monitoring section before the table grows large enough that you notice it the hard way.</p> <p><strong>Monitor for silence, not just failure:</strong> A failed run appears in <code>job_run_details</code>, but a job that stopped being scheduled at all leaves no trace. A periodic check that each critical job has a recent successful run catches both cases:</p> <pre><code class="language-sql">SELECT j.jobname, max(d.end_time) AS last_success FROM cron.job j LEFT JOIN cron.job_run_details d ON d.jobid = j.jobid AND d.status = 'succeeded' GROUP BY j.jobname HAVING max(d.end_time) &lt; now() - interval '1 day' OR max(d.end_time) IS NULL; </code></pre> <p>Any job this query returns hasn't succeeded in over a day, and deserves a look.</p> <h2 id="heading-conclusion">Conclusion</h2> <p>pg_cron turns PostgreSQL into its own scheduler. You define jobs in SQL, the database runs them, and the entire system — definitions, history, failures — is visible through ordinary queries.</p> <p>In this tutorial, you learned how the extension works under the hood, how to install it on your own servers and on managed services, how to write schedules (including pg_cron's seconds and last-day-of-month extensions), and how to apply it to the maintenance work every real database accumulates: pruning, rollups, refreshes, and vacuums. You also saw how to monitor jobs, manage permissions, and recognize the point where a real job queue or orchestrator becomes the better tool.</p> <p>If your infrastructure currently has a lonely server whose only purpose is running <code>psql</code> from a crontab, you now know how to retire it.</p> <p>Thanks for reading! I write about PostgreSQL and backend engineering. You can connect with me on <a href="https://linkedin.com/in/iyioladev">LinkedIn</a> and <a href="x.com/iyiola_dev_">X</a>.</p>