# Six Local Supabase Stacks, 61 Containers, and 96% Swap > Running six local Supabase stacks simultaneously pushed swap to 96% and caused repeated OOM failures during db reset. The real lesson is surfacing infrastructure exhaustion before blaming your code. - Author: Dil Ahdan (https://dil.dev/) - Published: 2026-10-08 - Updated: 2026-10-08 - Tags: supabase, docker, local-dev, debugging - Canonical: https://dil.dev/notes/six-local-supabase-stacks-resource-exhaustion/ ## Key takeaways - 61 containers across six Supabase stacks is enough to exhaust swap on a machine running other apps. - OOM failures during supabase db reset are infrastructure failures, not migration bugs. - 96% swap consumption is a blocking state that needs to be resolved before any further debugging. - Counting running containers before a reset is a cheap check that saves a lot of confusion. - Silently working around resource exhaustion hides the real problem and wastes time. Running six local Supabase stacks at the same time produced 61 Docker containers, pushed swap to 96 percent, and caused a repeated OOM failure every time `supabase db reset` was attempted. The failure looked like a database or migration problem. It was not. It was the machine running out of memory, and the only fix was to treat that as the actual problem. ## How You End Up With 61 Containers It happens gradually. You start a project, spin up a local Supabase stack, and leave it running while you open another project. Repeat that across a few weeks of context-switching and you end up with stacks that you forgot are still alive. - **Each stack is a full suite of services.** Database, auth, storage, realtime, the API gateway, and a handful of supporting containers. - **Six stacks, 61 containers.** That is the recorded number from this situation. Not a rough estimate. - **Nothing warns you.** Docker happily runs all of them until the machine cannot cope. The containers themselves are not the bug. The bug is not noticing they are all running. ## What 96% Swap Actually Means Swap at 96 percent means the machine has almost entirely exhausted physical RAM and is now using disk as overflow memory. Disk is orders of magnitude slower than RAM. - **Every memory allocation becomes expensive.** The OS is constantly moving pages between RAM and disk. - **Spiky operations get killed.** The kernel's OOM killer looks for processes to terminate when a new allocation cannot be satisfied. `supabase db reset` is a spiky operation. - **Other apps on the machine make it worse.** A browser, an editor, a build process: all of them are competing for the same shrinking pool. The 96 percent figure here was recorded while other applications were also running. That is a realistic dev machine state, not an edge case. ## Why db Reset Was the Thing That Broke `supabase db reset` is not a gentle operation. It stops the database container, wipes the volume, recreates the container, and then runs every migration in sequence. - **Container teardown and recreation spikes memory demand.** Docker needs headroom to pull images into memory, start new processes, and initialise the database engine. - **The spike arrives at the worst possible moment.** Swap is already at 96 percent. There is no headroom. - **The OOM killer fires.** The reset process is terminated mid-run. The error looks like a database failure. The migration SQL was almost certainly fine. The machine just could not execute the reset. ## The Diagnostic Mistake to Avoid When `supabase db reset` fails, the instinct is to look at the migration files. You check for syntax errors, look for a bad foreign key, wonder if a previous partial run left the schema in a broken state. - **That instinct is wrong here.** The schema is not the problem. - **The error message may not help.** OOM failures can surface as connection errors, timeout errors, or generic process exits depending on exactly what the kernel killed. - **You can waste a lot of time on the wrong layer.** Editing migrations, rolling back changes, adding debug logging: none of it helps when the machine is exhausted. The check that would have saved time: run `docker ps | wc -l` and `free -h` before touching any migration files. ## Surfacing Exhaustion as a Blocking State The recorded lesson from this situation is specific: infrastructure exhaustion is a blocking state to surface, not something to silently work around. That distinction matters. - **Silently working around it** looks like retrying the reset, restarting individual containers, or editing files in the hope that a different input produces a different result. - **Surfacing it** looks like stopping, measuring, and declaring that the machine cannot proceed until resource pressure is resolved. The second approach is slower in the moment and faster overall. Retrying a reset on a machine at 96 percent swap just produces the same failure again. ## The Practical Check Before Any Reset Before running `supabase db reset` on a machine that has been running for a while: - **Count your containers.** `docker ps` shows what is actually running. If you see stacks for projects you are not working on today, stop them. - **Check swap.** `free -h` on Linux. Activity Monitor on macOS. If swap is above 80 percent, stop containers before doing anything else. - **Check Docker Desktop limits.** On macOS and Windows, Docker runs inside a VM with a memory ceiling. That ceiling can be lower than the host machine's actual RAM, which makes the problem hit earlier than you expect. - **Only retry after the machine has headroom.** Not before. None of this is complicated. It is just easy to skip when you are in the middle of debugging something and assume the environment is fine. ## Infrastructure Failures Look Like Code Failures This is the broader pattern. When a tool fails, the first assumption is usually that the tool was used incorrectly, or that the code passed to it is wrong. That assumption is often right. But when the machine is under severe resource pressure, it is wrong. - **OOM failures are environment failures.** The code did not cause them. Fixing the code will not resolve them. - **The environment needs to be stable before debugging the application.** Running six stacks simultaneously is not a stable environment for any one of them. - **This applies beyond Supabase.** Any memory-intensive local service, any container-heavy workflow, any machine also running a browser and an editor: the same dynamic applies. The 61-container, 96-percent-swap situation is an extreme version of something that happens at smaller scales all the time. ## What I'd do differently - **Stop stacks at the end of a session.** `supabase stop` takes seconds. Leaving stacks running overnight across multiple projects is how you arrive at 61 containers without noticing. - **Add a container count check to the start of any debugging session.** Not a script, just a habit. `docker ps` before touching anything. - **Treat the first OOM failure as a signal to measure, not retry.** One failed reset is information. Retrying three times on an exhausted machine is just noise. - **Set Docker Desktop memory limits explicitly.** Rather than letting it compete freely with the rest of the machine, give it a ceiling that leaves room for the editor and browser you are definitely also running. ## Quick answers **How many Docker containers does a single local Supabase stack use?** A single local Supabase stack spins up roughly ten containers covering the database, auth, storage, realtime, and supporting services. Six stacks running simultaneously totalled 61 containers in this case. **Why does supabase db reset fail with an OOM error?** The reset process tears down and rebuilds the database container, which spikes memory demand at exactly the moment when available RAM and swap are already under pressure. If the system is near exhaustion, the kernel kills the process before it finishes. The migration SQL itself is usually fine. **How do I check whether my local machine is actually out of memory before debugging further?** Run docker stats to see live container memory consumption, and check swap usage with free -h on Linux or Activity Monitor on macOS. If swap is above 80 to 90 percent, stop containers you are not actively using before doing anything else. **Is it safe to run multiple Supabase local stacks at the same time?** Technically yes, but each stack is a full set of services and the memory cost adds up fast. If you are also running a browser, an editor, and other dev tools, six stacks is almost certainly too many for a single machine without very generous RAM. **What is the right order of operations when supabase db reset keeps failing?** First confirm resource state: check swap, check container count, stop anything you are not using. Only once the machine has headroom should you retry the reset. Retrying on an exhausted machine just produces the same failure. **Does Docker Desktop have a memory limit that makes this worse?** Yes. Docker Desktop on macOS and Windows runs inside a VM with a configurable memory ceiling. If that ceiling is set conservatively, 61 containers will hit it well before the host machine itself runs out of RAM.