Docker Alternatives for Local Postgres Dev: A 2026 Comparison

TL;DR

• Podman and Colima swap the Docker licensing/host layer but you still run 12 containers, so RAM barely moves
• PGlite is tiny but you lose the Supabase SDK and have to build your own auth
• A single-binary Supabase-compatible backend cut my local stack from ~1.6 GB to ~100 MB with the SDK unchanged
• Docker still wins for prod parity; the question is whether local dev is where you need it

The test setup

One project, five backends. The app: Next.js, 12 tables, auth, one realtime subscription. The machine: a 16 GB Apple Silicon laptop, which is what a huge share of indie devs are actually working on. For each approach I looked at steady-state RAM, cold boot, and whether my app code needed changes.

My numbers are from my machine and my project. Yours will differ; the ratios probably won't.

Approach 1: Docker Compose + Supabase (baseline)

The documented path. supabase start brings up 12 containers: Postgres, PostgREST, GoTrue, Realtime, Storage, Kong, Studio, and friends.

supabase start
docker stats --no-stream

On my machine that stack idled around 1.6 GB of RAM, with cold boots taking the better part of a minute. App code: works out of the box, obviously. This is the reference everything else gets measured against.

Approach 2: Podman + Supabase

Podman is a daemonless, open-source container engine and the go-to answer to Docker Desktop licensing.

podman machine init --memory 4096
podman machine start

The swap is real for licensing and rootless security. It is not a RAM story: you are still running the same 12 containers with the same runtimes inside a Linux VM. My steady-state numbers were in the same band as Docker. Pick Podman because of licensing or philosophy, not because your fans are loud.

Approach 3: Colima + Supabase

Colima replaces the Docker Desktop VM with a leaner Lima-based one while keeping the Docker CLI and socket.

colima start --memory 4
docker context use colima

The host layer genuinely gets lighter and you drop the Desktop app entirely. But the workload is unchanged: 12 containers, one gateway, all the sibling runtimes. You claw back some host overhead, not the container tax itself.

Approach 4: PGlite + custom auth

PGlite runs Postgres compiled to WASM, in-process, no containers at all. For pure database work it is astonishingly light, starts instantly, and can even run in the browser.

The catch for a Supabase-style app: there is no PostgREST, no GoTrue, no Realtime. My auth flow and supabase-js calls had nowhere to go, so this approach means rewriting the data layer and rolling your own auth for local dev. Great for tests and toy schemas, rough for "run my actual app locally."

Approach 5: Single-binary Supabase-compatible

The last approach keeps the Supabase API surface but drops the container model: one binary that bundles real Postgres with the REST, auth, and realtime layers in a single process. Tinbase is the one I used: real Postgres 17, works with the official supabase-js SDK unchanged, MIT-licensed.

./tinbase start

On my machine: ~100 MB steady-state, cold boot in seconds, zero app code changes. The tradeoffs are the single-process ones: no container isolation, and less mature ops tooling than the Docker ecosystem.

Summary

When to pick what

• Team mirrors prod on k8s, 32 GB machines → stay on Docker Compose
• Docker Desktop licensing is the problem → Podman
• You want the Docker CLI without the Desktop app → Colima
• Unit tests and throwaway schemas → PGlite
• Solo dev / prototyping on 16 GB, Supabase-style app → single-binary backend

Conclusion

Podman and Colima answer "how do I run Docker cheaper." The more interesting 2026 question is "does local Postgres dev need containers at all," and for a lot of solo and small-team work the answer is no. Try the swap for a week; the rollback path is just supabase start.

What's your local stack idling at right now? Run docker stats --no-stream and drop the number in the comments.