[HN Gopher] How to Run CRON Jobs in Postgres Without Extra Infra...
       ___________________________________________________________________
        
       How to Run CRON Jobs in Postgres Without Extra Infrastructure
        
       Author : Liriel
       Score  : 31 points
       Date   : 2025-05-28 10:14 UTC (2 days ago)
        
 (HTM) web link (wasp.sh)
 (TXT) w3m dump (wasp.sh)
        
       | xnx wrote:
       | No mention of pg_cron?
        
         | etchalon wrote:
         | It's what I expected to be talked about exclusively in the
         | article based on the title.
        
         | eddythompson80 wrote:
         | apples and oranges?
         | 
         | pg_cron is for pg specific cron tasks. You use pg_cron to
         | truncate a table, compute pg views, values, aggregates, etc.
         | Basically just running PG queries on a CRON schedule.
         | 
         | pg_cron itself won't run an external script for you. Like you
         | can't do                   SELECT cron.schedule('0/30 * * * *',
         | $$ ./sendEmails.sh $$);
         | 
         | you can use pg_cron to insert a job-row in a jobs table that
         | you have some consumer that runs a `select * from jobs where
         | status = 'pending' limit 1;`. Then you're on the hook to handle
         | the pg updates for dispatching and handling updates, job
         | status, etc. You could even call that implementation pg-boss if
         | it's not taken.
        
       | SoftTalker wrote:
       | Cron isn't an acronym; it's not normally written in all caps.
       | 
       | Cron's name originates from Chronos, at least according to
       | Wikipedia.
        
       | NeutralForest wrote:
       | Tangential since it's not PG related but I'm more and more moving
       | away from cron and I prefer using systemd timers (I'm on RHEL at
       | work). I just find the interface to list and manager timers
       | better and I can just handle everything like a systemd service
       | anyways.
        
       | zie wrote:
       | I have nothing against pg_boss[0] from the articel (I don't know
       | anything about it), but there are plenty of queues and crons and
       | schedulers for PG
       | 
       | Some others:
       | 
       | * https://github.com/LaunchPlatform/bq
       | 
       | * https://github.com/cybertec-postgresql/pg_timetable
       | 
       | * https://github.com/pgmq/pgmq
       | 
       | * https://github.com/riverqueue/river
       | 
       | * https://github.com/oban-bg/oban
       | 
       | * https://github.com/pgadmin-org/pgagent
       | 
       | * https://github.com/citusdata/pg_cron
       | 
       | etc. There are plenty of options to choose from.
       | 
       | 0: https://github.com/timgit/pg-boss
        
         | TkTech wrote:
         | Gonna toss my own hat in the ring there for the python+postgres
         | ecosystem :)
         | 
         | https://github.com/tktech/chancy
         | 
         | > As a rule of thumb, if you're processing less than 1000 jobs
         | per day or your jobs are mostly lightweight operations (like
         | sending emails or updating records), you can stick with this
         | solution.
         | 
         | This seems... excessively low? Chancy is on the heavier side
         | and happily does many millions of jobs per day. Postgres has no
         | issue with such low throughput, even on resource constrained
         | systems (think a $5 vps). Maybe they meant 1000 per second?
        
       | wewewedxfgdf wrote:
       | There's many ways to skin this cat. Personally I invested all my
       | knowledge and focus into systemd timers. No doubt you have your
       | own ways that make sense for you.
        
       ___________________________________________________________________
       (page generated 2025-05-30 23:00 UTC)