Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

The Janitor process in Realtime has a 10-minute startup delay (janitor_run_after_in_ms: 600000) before creating partitions for the realtime.messages table. This causes silent failures when using realtime.send() in local development after database resets, as the function expects partitions to exist but doesn't create them on demand.

To Reproduce

Steps to reproduce the behavior:

Scenario 1: Fresh Install or First Startup

1. Set up Supabase locally
2. Immediately try to use realtime.send() in a function or query
3. The function appears to succeed but no messages are stored
4. Check realtime.messages and find no data

Scenario 2: After Database Reset

1. Run supabase db reset (which wipes out existing partitions)
2. Try to use realtime.send() in a function or query
3. The function appears to succeed but no messages are stored
4. Behavior persists until the Janitor's next scheduled run (up to 4 hours later)

Example SQL that fails silently:

SELECT realtime.send(
  jsonb_build_object('data', 'test'),
  'test_event',
  'test_topic',
  true
);

Note: Simply restarting Supabase without a database reset doesn't cause this issue, as partitions persist in the database. The Janitor proactively creates partitions for today and the next 3 days, so day transitions are handled automatically once it has run initially.

Expected behavior

Either:

1. The Janitor should run with minimal delay in development environments
2. The realtime.send() function should create the necessary partition if it doesn't exist
3. At minimum, realtime.send() should return an error rather than failing silently

System information

• OS: Linux
• Version of Supabase CLI: v2.21.1

Additional context

I found this issue while writing pgTAP tests that needed to verify Realtime notifications were working. Messages were silently failing to be stored because partitions didn't exist.

I've verified that the Janitor is enabled in the Supabase CLI environment (RUN_JANITOR=true), but the 10-minute delay is causing problems for development workflows where database resets are common.

While this 10-minute delay might be reasonable in production where services run continuously, it's particularly problematic in development environments where developers frequently reset their databases.

The current workaround is to manually create the partition:

DO $$
DECLARE
  today date := current_date;
  partition_name text := 'messages_' || to_char(today, 'YYYY_MM_DD');
BEGIN
  EXECUTE format(
    'CREATE TABLE IF NOT EXISTS realtime.%I PARTITION OF realtime.messages FOR VALUES FROM (%L) TO (%L)',
    partition_name,
    today,
    today + interval '1 day'
  );
END;
$$;

Note: I'm not an Elixir developer, so I've used Claude and ripgrep to help analyze the codebase. Please correct me if I've misunderstood anything about how the Janitor configuration works.