Scheduled jobs are here: pg_cron on Layerbase Cloud PostgreSQL

Every PostgreSQL database on Layerbase Cloud now has a Scheduled jobs tab. It runs SQL on a schedule inside the database with pg_cron: nightly cleanups, materialized view refreshes, a VACUUM ANALYZE on the table that churns the most. No separate worker, no external cron box, no app process that has to stay up just to fire a query at 3 AM.

Here is what you can do with it, what it looks like in SQL, and the one rule about sleeping databases you should know before you rely on it.

What the tab does

Scheduling is opt-in for each database. On the database's page, open Scheduled jobs and click Turn on scheduled jobs. Turning it on restarts the database once, so open connections drop and reconnect; pick a quiet moment. Turning it off later also restarts once, and it keeps your jobs and their history, so turning it back on brings back the same jobs.

Once it is on, the database owner can:

• Create a job with New job, optionally starting from a template: Refresh a materialized view, Delete rows older than N days, or VACUUM ANALYZE on one table or the whole database.
• Pick a schedule preset, or type a five-field cron expression (in UTC) or an interval such as 10 seconds. The line under the field says in words when the job will run, and pg_cron itself checks the schedule when you save.
• Edit, pause, resume, or delete any job from its row. Editing keeps the job's id and its run history.
• Read Run history for every job: status, start and end time, duration, and the return message, newest first. Layerbase keeps completed runs for up to seven days or the latest 10,000, whichever is smaller.

A command that deletes rows, including the Delete rows template, asks you to confirm that it permanently deletes rows on every run before it saves. Team members see every job and its history, and they can manage jobs with SQL.

Job commands stay out of our logs. When a job is created or changed, the audit trail records that it happened, not the SQL inside it.

Requirements

Scheduled jobs need a supported PostgreSQL version. If your database runs an older version, the tab tells you. Support can update an older minor version in place with the same connection string; an older major version cannot move in place, so create a new database on a supported version and migrate into it.

Some existing databases need a server update first. If the tab says your database's server needs an update, run it from the database's Settings, under Maintenance. It briefly restarts the databases that share that server, and your data, connection string, and settings stay the same. Support can run it for you too.

The same thing in SQL

You do not have to use the tab. Once scheduled jobs are on, the jobs live in your own database, so they travel with its backups and exports, and you can manage them with plain pg_cron calls. Connected to your database:

CREATE TABLE IF NOT EXISTS sessions (
  id bigserial PRIMARY KEY,
  user_id bigint NOT NULL,
  expires_at timestamptz NOT NULL
);

-- Every day at 03:00 UTC, drop sessions that expired more than a day ago
SELECT cron.schedule(
  'purge-expired-sessions',
  '0 3 * * *',
  $$DELETE FROM sessions WHERE expires_at < now() - interval '1 day'$$
);

-- What is scheduled
SELECT jobid, jobname, schedule, active FROM cron.job;

-- What ran, and how it went
SELECT status, return_message, start_time
FROM cron.job_run_details
ORDER BY start_time DESC
LIMIT 5;

-- Remove it
SELECT cron.unschedule('purge-expired-sessions');

Refresh the tab and a job you made with SQL shows up there, with its run history. If you would rather opt in by hand instead of using the button, the pg_cron section of Database lifecycle walks through the ALTER SYSTEM steps. The step that matters most is setting cron.database_name to your database, so the jobs live next to your data instead of in the postgres database.

How it behaves with sleep

This is the part to read twice. pg_cron runs inside the database, so a job runs only while its database is awake.

• A schedule never wakes a sleeping database.
• Runs that fall due while it sleeps are skipped, and they are not replayed when it wakes.
• A running job does not count as activity, so it will not keep the database awake either.

Free databases sleep after 15 idle minutes. Solo and Pro databases sleep after six idle hours unless they are pinned always-on (Settings > Availability > Always on, see the always-on pool), and databases on a dedicated server do not sleep. So scheduled jobs work on every plan, but on Free they run only while the database happens to be awake. If a job has to fire on time, put it on a paid database and pin it always-on. The tab tells you when a database can sleep.

Opening the tab does not wake the database. While it sleeps, the tab says so and offers a Wake database button; waking is always your call.

Copies get the same care. Branching, copying, resetting, or restoring a database leaves its scheduler paused, so the same job never runs in two places. The job definitions are kept, and the tab shows a Resume scheduling button with a list of every active job to review first. I wrote more about how sleep compares with pausing and archiving across hosts in Sleep vs pause vs archive.

Coming from Supabase

If you run pg_cron on Supabase, Neon, RDS, or another Postgres host, the migration tool now reads your jobs from the source before it copies anything. When the database owner starts the import and the new database runs a supported PostgreSQL version, Layerbase turns scheduled jobs on (one restart) and recreates every job in your new database, paused. Nothing fires until you have looked at it in the Scheduled jobs tab and resumed it.

Jobs that call pg_net or Vault are flagged in the import report. Neither exists on Layerbase, so a job that makes HTTP calls from the database will fail as written. Move that work into your app or a queue, or rewrite the job as plain SQL.

On another version, or when a team member started the import, the report lists the job definitions instead, and once scheduled jobs are on the owner can create them all, paused, with Create these jobs (paused). A name that already exists is skipped, never overwritten. The full Supabase walkthrough, including what else the import report separates out, is in Migrating from Supabase to Layerbase.

Try it

Open a PostgreSQL database on a supported version in the dashboard, click Scheduled jobs, and turn it on. The full walkthrough of the tab, including every state it can show, is at /docs/scheduled-jobs, and you can see where it sits next to everything else on the features page. If you do not have a database yet, create a PostgreSQL database and try a 10-second test job first.

FAQ

Which databases support scheduled jobs on Layerbase?

PostgreSQL databases on a supported version; the current list is in the Scheduled jobs requirements. Support can update an older minor version in place. Older major versions need a new database and a migration.

Do scheduled jobs run while a database is asleep?

No. A schedule never wakes a sleeping database, and runs missed while it sleeps are not replayed. Pin a paid database always-on if a job must run on time.

Can pg_cron jobs make HTTP requests on Layerbase?

No. pg_net is not available, so jobs cannot make HTTP calls from the database. Migrated jobs that use pg_net or Vault are flagged in the import report.