From 4f480e0ed6dd91c8862f00e58c6bd7cd534e76ea Mon Sep 17 00:00:00 2001 From: Steven Eubank <47563310+smeubank@users.noreply.github.com> Date: Tue, 27 Jan 2026 08:06:18 +0000 Subject: [PATCH] Add amdonition about schema to choose - what schema should i choose when configuring pg_cron? - what is internal workings that is not really relevant to 90% of decs? - does it matter if i choose extension or some public schema i created? - realistically what would i functionally do with the extension schema for cron? Do I need to think about this? --- apps/docs/content/guides/cron.mdx | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/apps/docs/content/guides/cron.mdx b/apps/docs/content/guides/cron.mdx index ba34687eb40..7c55396e6b4 100644 --- a/apps/docs/content/guides/cron.mdx +++ b/apps/docs/content/guides/cron.mdx @@ -29,6 +29,13 @@ Under the hood, Supabase Cron uses the [`pg_cron`](https://github.com/citusdata/ The extension creates a `cron` schema in your database and all Jobs are stored on the `cron.job` table. Every Job's run and its status is recorded on the `cron.job_run_details` table. + + +You will be asked to select a schema. The default we recommend is the `extension` schema, which is mostly for **pg_cron’s internal metadata** (job definitions + run history). You usually don’t need to touch it directly — managing jobs in the Dashboard is the normal workflow. Your cron job logic can still read and write data in your own schemas (like `public` or any custom schema). + + + + The Supabase Dashboard provides an interface for you to schedule Jobs and monitor Job runs. You can also do the same with SQL. ## Resources