Summary

On macOS, the native stack engine runs out of System V shared memory segments once about 30 stacks are running, and supabase start then fails for every new checkout or branch.

What happens

The stack engine keeps one stack per checkout and branch, and a stack keeps running after its shell exits. Each running stack's Postgres creates a System V shared memory segment. macOS allows 32 segments on the whole machine by default (sysctl kern.sysv.shmmni prints 32), so with git worktrees and short-lived branches the limit is reached in a few days. ipcs -m shows the segments in use; on my machine 31 of 32 were taken before I stopped two stacks.

Steps to reproduce

1. On macOS, set [experimental] stack = true in supabase/config.toml.
2. Run supabase start --runtime native in about 30 worktrees or branches without stopping them.
3. Run supabase start --runtime native in one more.

The last start fails because Postgres can't create its segment. supabase stack list shows the other stacks as reachable.

Environment

• Supabase CLI 2.121.0, native runtime
• macOS 26 (Darwin 25.6), Apple silicon
• kern.sysv.shmmni: 32

Suggestions

• Name the cause when Postgres fails on shmget, and point to supabase stack list and supabase stop --stack-id.
• Stop the Postgres of a stack that has been idle for a while, the way the other services already stop when idle.
• Offer a command that stops the stacks of branches that no longer exist or were merged. We use a small script for this today: it reads supabase stack list --output-format json, matches branch_context against git branch --merged main for the repo and its worktrees, and calls supabase stop --stack-id.