Free Nano: process burst every 10 minutes, swap jumps with it. What is it?

[kostiagaracimjvich-arch]

A small project on Free/Nano shows a process burst about every 10 minutes, and swap jumps with it. I'd like to know what it is.

Environment: eu-west-1, Nano, 406 MB RAM, 1 GB swap. Test copy on image 17.11.0.003, production on 17.6.1.084.

Test copy, no clients connected, from /customer/v1/privileged/metrics (30 Oct, UTC). Over 125 minutes there were 12 bursts of 636-671 forks, one per 10-minute slot. Other windows stayed at 65 or less.

time      forks  swap_MB  avail_MB
22:01:46    +20      270       172
22:03:16   +664      283       188
22:04:46    +46      282       181
22:11:46    +22      280       171
22:13:16   +663      288       193
22:14:46    +63      276       168

Production, Observability charts only (31 Oct, UTC, pool still 10), CPU about 98% idle at the last point:

13:55  swap 509 MB
14:11  swap 464 MB
14:24  swap 374 MB

Production edge_logs for the last day: 649 requests, 145 over 1 s, 99 with upstream time over 1 s, 3 with more than 1 s in front of upstream. So this does not look like #52011. Some of the 145 are heavy admin RPCs (about 5 s); I haven't separated them.

With 200 simulated users on the test copy, swap above about 400 MB before a burst reached 512 MB every time. Worst run on default settings: p95 40 s, 141 failed of 17,644 requests. PostgREST pool 3 instead of 10 kept swap under 380 MB before bursts in two runs, so I have a workaround.

I can't see the process list. At those moments the schema cache load counter did not move and the Postgres log was empty.

Questions:

1. What runs every 10 minutes and spawns about 650 processes?
2. How much memory should it use on Nano?
3. Can it run less often?

I collected the numbers with my own scripts; an AI assistant helped write this post. I can share the full metric dumps.

[Rustaman1280]

Here is what is happening with the 10-minute process burst and why swap spikes on Nano instances:

1. What runs every 10 minutes and spawns ~650 processes?

In Supabase managed Postgres instances, the host runs automated internal platform housekeeping and metric-collection daemons:

• Per-object metric & health collection: The Supabase management daemon / host agent collects system and database metrics periodically. A burst of ~650 process forks in Linux (/proc/stat processes metric) is characteristic of a shell script or loop iterating over PostgreSQL catalog objects (such as tables, views, sequence stats, or connection states) where subshells or external utility binaries (psql, awk, sed, date, cut) are executed per object.
• Why ~650 forks? A default Supabase PostgreSQL database contains ~500 to 650 system catalog tables, views, and internal schemas (auth, storage, realtime, graphql, pg_catalog, information_schema, extensions). When a scheduled sweep audits or checks these relations sequentially, every child subshell increments the Linux fork counter.

2. Why does swap jump on Free/Nano?

• A Nano instance has only 406 MB of physical RAM.
• The baseline footprint of PostgreSQL (shared_buffers, system cache, catalog cache), Kong API gateway, PostgREST, and Gotrue easily consumes 300 MB to 350 MB of resident memory at idle.
• When 650 processes fork over a short window, Linux copy-on-write (COW) page duplication and kernel task struct allocations momentarily exceed the remaining ~50-80 MB of free physical RAM.
• The Linux kernel memory manager immediately pushes inactive anonymous pages into the 1 GB swap partition to accommodate the peak memory pressure. Once the burst completes, pages remain in swap until re-referenced, which is why swap stays elevated.

3. Can it run less often, and how to optimize?

• Platform level: On the Free plan, internal host cron and platform monitoring intervals are controlled by Supabase infrastructure management and cannot be reconfigured directly by users.
• Your PostgREST pool reduction (from 10 to 3) is the ideal mitigation:
  Each idle PostgREST connection to PostgreSQL holds a backend worker process consuming roughly 5 to 10 MB of RSS. Reducing the pool from 10 to 3 frees up ~35-70 MB of physical RAM, which gives the host just enough headroom to absorb the 10-minute fork burst without hitting severe swap thrashing.
• Additional tips for Nano stability:
  1. Keep work_mem at default (do not raise it beyond 4MB on Nano).
  2. Avoid unindexed foreign keys or complex joins during scheduled windows to prevent Postgres backends from reserving large memory chunks.
  3. Keep client-side connection pooling lean so background spikes do not trigger memory pressure.

[aantti]

This isn't accurate, I'm sorry.

[vanshulgoyal101]

One caution about the explanation above: if your "forks" series is the Linux /proc/stat processes counter, that counts forks since boot, not processes simultaneously resident (proc_stat(5)). Assuming no counter reset, a +664 delta means 664 fork events in the sampling interval; it does not identify the job, peak concurrency, or memory consumed. The measurements alone cannot establish that a specific Supabase housekeeping job caused the swap increase.

For the next comparison, align memory available, swap-in/out rates (where exposed), CPU and disk I/O, and request latency/errors over the same windows; Supabase documents its Metrics API and Reports. Comparing pool 3 and pool 10 with the same workload, including connection waits and errors, would help distinguish a useful mitigation from a throughput trade-off. Your two pool-3 runs are a useful lead, but not proof of the underlying cause.

I cannot determine from these counters which service owns the schedule, its expected memory footprint, or whether customers can tune it; those need confirmation from Supabase. AI-assisted; I have not inspected your project or run your workload.