Developer runs full Supabase stack locally in ~100 MB of RAM without Docker

A developer writing on dev.to has documented replacing the official Docker-based local Supabase stack — twelve containers, roughly 1.6 GB of RAM and a 45-second startup — with a single ~58 MB executable that idles at about 98 MB and boots in roughly 2.5 seconds, with no changes to application code beyond a connection string.

The tool behind the switch

The setup the author landed on is Tinbase, described in the post as a single-file binary that bundles a real Postgres 17 instance together with auth, realtime, edge functions, webhooks and cron. Because it exposes the same HTTP and Postgres endpoints as hosted Supabase, the standard supabase-js client connects to it unchanged. The author reports that the only application-side edit was pointing SUPABASE_URL at localhost:4000 instead of localhost:54321.

Tinbase serves Postgres on port 5432 and mirrors Supabase's URL structure for REST (/rest/v1), auth (/auth/v1), realtime (/realtime/v1) and storage (/storage/v1), plus its own admin UI on the same port.

The migration, in practice

According to the post, the move took five steps: install via a curl-piped shell script (one binary lands in ~/.tinbase/bin), run tinbase init and tinbase start, copy existing Supabase migrations into the project and reset the database, update the connection URL in the app, then stop Docker and prune roughly 2.3 GB of images and volumes.

Because the database is genuine Postgres 17, the author says row-level security policies behaved identically and migrations ran without modification. Edge functions keep their Deno runtime and deploy through a comparable command.

The numbers, with a caveat

All benchmarks come from the author's own M1 Air under a ten-minute development workload, so they are a single self-reported data point rather than an independent test. Even so, the deltas are large:

• Cold boot: 45 s to 2.5 s
• Warm boot: 15 s to 1.2 s
• Steady-state RAM: 1,626 MB to 98 MB
• Disk footprint: 2.3 GB to 58 MB
• Idle CPU: 4-8% to 0.1-0.4%

Under active load with realtime and edge functions firing, RAM reportedly peaked around 250 MB, versus more than 2 GB for the Docker stack.

Where it falls short

The author is upfront about the rough edges. Tinbase's admin UI is a different product from Supabase Studio. Newer hosted-only features, including some analytics endpoints and the vector search integration, are absent. The edge function environment is not byte-identical either — the author hit one case where a SUPABASE_URL environment variable held a different value than in the Docker runtime.

The post also draws a clear boundary: this is a local development replacement, not a Supabase substitute. Production still belongs on hosted Supabase for its SLA and scaling, and the approach strains with multi-terabyte local datasets or apps that need every hosted feature to match exactly.

Why it matters

The interesting part of the write-up is less the RAM savings than the workflow cost the author attributes to Docker overhead: skipping local runs for short sessions, testing schema changes against hosted Supabase because local was slow, and non-backend teammates defaulting to staging. After the switch, the author says designers on the team started running the app locally for the first time because setup was a single command.

For anyone whose local Supabase stack is a background tax on battery, memory and iteration speed, the post makes a concrete case that the container abstraction itself — not image size — can be the thing worth removing. Given it is one author's account of one tool, teams considering the same move should benchmark against their own workloads and check Tinbase's compatibility matrix for the specific Supabase features they rely on.